File: rfc9061.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (6429 lines) | stat: -rw-r--r-- 295,486 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9061: A YANG Data Model for IPsec Flow Protection Based on Software‑Defined Networking (SDN)</title>
<meta content="Rafa Marin-Lopez" name="author">
<meta content="Gabriel Lopez-Millan" name="author">
<meta content="Fernando Pereniguez-Garcia" name="author">
<meta content="
       This document describes how to provide IPsec-based
            flow protection (integrity and confidentiality) by means
            of an Interface to Network Security Function (I2NSF)
            Controller.  It considers two main well-known scenarios
            in IPsec: gateway-to-gateway and host-to-host. 
            The service described in this document allows the
            configuration and monitoring of IPsec Security
            Associations (IPsec SAs) from an I2NSF Controller to one
            or several flow-based Network Security Functions (NSFs)
            that rely on IPsec to protect data traffic.         
       
        This document focuses on the I2NSF NSF-Facing
            Interface by providing YANG data models for configuring
            the IPsec databases, namely Security Policy Database
            (SPD), Security Association Database (SAD), Peer
            Authorization Database (PAD), and Internet Key Exchange 
     Version 2 (IKEv2). This allows IPsec SA establishment
            with minimal intervention by the network administrator. 
     This document defines three YANG modules, but it does not define any new protocol.
       
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="NSF" name="keyword">
<meta content="SDN" name="keyword">
<meta content="IPsec" name="keyword">
<meta content="9061" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9061.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9061" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection-14" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9061</td>
<td class="center">IPsec Flow Protection Based on SDN</td>
<td class="right">July 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Marin-Lopez, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9061" class="eref">9061</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-07" class="published">July 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">R. Marin-Lopez</div>
<div class="org">University of Murcia</div>
</div>
<div class="author">
      <div class="author-name">G. Lopez-Millan</div>
<div class="org">University of Murcia</div>
</div>
<div class="author">
      <div class="author-name">F. Pereniguez-Garcia</div>
<div class="org">University Defense Center</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9061</h1>
<h1 id="title">A YANG Data Model for IPsec Flow Protection Based on Software‑Defined Networking (SDN)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes how to provide IPsec-based
            flow protection (integrity and confidentiality) by means
            of an Interface to Network Security Function (I2NSF)
            Controller.  It considers two main well-known scenarios
            in IPsec: gateway-to-gateway and host-to-host. 
            The service described in this document allows the
            configuration and monitoring of IPsec Security
            Associations (IPsec SAs) from an I2NSF Controller to one
            or several flow-based Network Security Functions (NSFs)
            that rely on IPsec to protect data traffic.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2"> This document focuses on the I2NSF NSF-Facing
            Interface by providing YANG data models for configuring
            the IPsec databases, namely Security Policy Database
            (SPD), Security Association Database (SAD), Peer
            Authorization Database (PAD), and Internet Key Exchange 
     Version 2 (IKEv2). This allows IPsec SA establishment
            with minimal intervention by the network administrator. 
     This document defines three YANG modules, but it does not define any new protocol.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9061">https://www.rfc-editor.org/info/rfc9061</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-sdn-based-ipsec-management-" class="xref">SDN-Based IPsec Management Description</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-ike-case-ikev2-ipsec-in-the" class="xref">IKE Case: IKEv2/IPsec in the NSF</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-ike-less-case-ipsec-no-ikev" class="xref">IKE-less Case: IPsec (No IKEv2) in the NSF</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-ike-case-vs-ike-less-case" class="xref">IKE Case vs. IKE-less Case</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-rekeying-process" class="xref">Rekeying Process</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-nsf-state-loss" class="xref">NSF State Loss</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-nat-traversal" class="xref">NAT Traversal</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-nsf-registration-and-discov" class="xref">NSF Registration and Discovery</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-yang-configuration-data-mod" class="xref">YANG Configuration Data Models</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-the-ietf-i2nsf-ikec-module" class="xref">The 'ietf-i2nsf-ikec' Module</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.1.2.1">
                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-data-model-overview" class="xref">Data Model Overview</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.1.2.2">
                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-yang-module" class="xref">YANG Module</a></p>
</li>
                </ul>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-the-ietf-i2nsf-ike-module" class="xref">The 'ietf-i2nsf-ike' Module</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-data-model-overview-2" class="xref">Data Model Overview</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-example-usage" class="xref">Example Usage</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-yang-module-2" class="xref">YANG Module</a></p>
</li>
                </ul>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-the-ietf-i2nsf-ikeless-modu" class="xref">The 'ietf-i2nsf-ikeless' Module</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.3.2.1">
                    <p id="section-toc.1-1.5.2.3.2.1.1"><a href="#section-5.3.1" class="xref">5.3.1</a>.  <a href="#name-data-model-overview-3" class="xref">Data Model Overview</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.3.2.2">
                    <p id="section-toc.1-1.5.2.3.2.2.1"><a href="#section-5.3.2" class="xref">5.3.2</a>.  <a href="#name-example-usage-2" class="xref">Example Usage</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.5.2.3.2.3">
                    <p id="section-toc.1-1.5.2.3.2.3.1"><a href="#section-5.3.3" class="xref">5.3.3</a>.  <a href="#name-yang-module-3" class="xref">YANG Module</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-ike-case" class="xref">IKE Case</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-ike-less-case" class="xref">IKE-less Case</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-yang-modules" class="xref">YANG Modules</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-xml-configuration-example-f" class="xref">XML Configuration Example for IKE Case (Gateway-to-Gateway)</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-xml-configuration-example-fo" class="xref">XML Configuration Example for IKE-less Case (Host-to-Host)</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-C" class="xref">Appendix C</a>.  <a href="#name-xml-notification-examples" class="xref">XML Notification Examples</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-D" class="xref">Appendix D</a>.  <a href="#name-operational-use-case-exampl" class="xref">Operational Use Case Examples</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#appendix-D.1" class="xref">D.1</a>.  <a href="#name-example-of-ipsec-sa-establi" class="xref">Example of IPsec SA Establishment</a></p>
<ul class="compact ulBare toc ulEmpty">
<li class="compact ulBare toc ulEmpty" id="section-toc.1-1.12.2.1.2.1">
                    <p id="section-toc.1-1.12.2.1.2.1.1"><a href="#appendix-D.1.1" class="xref">D.1.1</a>.  <a href="#name-ike-case-2" class="xref">IKE Case</a></p>
</li>
                  <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.12.2.1.2.2">
                    <p id="section-toc.1-1.12.2.1.2.2.1"><a href="#appendix-D.1.2" class="xref">D.1.2</a>.  <a href="#name-ike-less-case-2" class="xref">IKE-less Case</a></p>
</li>
                </ul>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#appendix-D.2" class="xref">D.2</a>.  <a href="#name-example-of-the-rekeying-pro" class="xref">Example of the Rekeying Process in IKE-less Case</a></p>
</li>
              <li class="compact ulBare toc ulEmpty" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#appendix-D.3" class="xref">D.3</a>.  <a href="#name-example-of-managing-nsf-sta" class="xref">Example of Managing NSF State Loss in the IKE-less Case</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-E" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact ulEmpty ulBare toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-F" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
                Software-Defined Networking (SDN) is an architecture
                that enables administrators to directly program,
                orchestrate, control, and manage network resources
                through software.
                The SDN paradigm relocates the control of network 
                resources to a centralized entity, namely the SDN 
                Controller.
                SDN Controllers configure and manage distributed
                network
                resources and provide an abstracted view of the
                network
                resources to SDN applications.
                SDN applications can customize and automate the
                operations
                (including management) of the abstracted network
                resources in a programmable manner via this interface <span>[<a href="#RFC7149" class="xref">RFC7149</a>]</span>
        <span>[<a href="#ITU-T.Y.3300" class="xref">ITU-T.Y.3300</a>]</span>
        <span>[<a href="#ONF-SDN-Architecture" class="xref">ONF-SDN-Architecture</a>]</span>
        <span>[<a href="#ONF-OpenFlow" class="xref">ONF-OpenFlow</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
                Recently, several network scenarios now demand a centralized
                way of managing different security aspects, for example,
                Software-Defined WANs (SD-WANs). SD-WANs are SDN extensions
                providing software abstractions to create secure network
                overlays over traditional WAN and branch networks. SD-WANs
                utilize IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> as an underlying
                security protocol. The goal of SD-WANs is to provide flexible
                and automated deployment from a centralized point to enable
                on-demand network security services, such as IPsec Security
                Association (IPsec SA) management. 
                Additionally, Section <span><a href="https://www.rfc-editor.org/rfc/rfc8192#section-4.3.3" class="relref">4.3.3</a> (<a href="https://www.rfc-editor.org/rfc/rfc8192#section-4.3.3" class="relref">"Client-Specific Security Policy in Cloud
                VPNs"</a>)</span> of <span>[<a href="#RFC8192" class="xref">RFC8192</a>]</span>
                describes another example use case for a cloud data center
                scenario. The use case in <span>[<a href="#RFC8192" class="xref">RFC8192</a>]</span> states that "dynamic key
                management is critical for securing the VPN and the
                distribution of policies".  These VPNs can be established using
                IPsec.  The management of IPsec SAs in data centers using a
                centralized entity is a scenario where the current
                specification may be applicable.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
                Therefore, with the growth of SDN-based scenarios where
                network resources are deployed in an autonomous manner,
                a mechanism to manage IPsec SAs from a centralized entity
                becomes more relevant in the industry.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4"> In response to this need, the Interface to Network Security
                Functions (I2NSF) charter states that the goal of this 
                working group is "to define a set of software interfaces and 
                data models for controlling and monitoring aspects of 
                physical and virtual NSFs". As defined 
                in <span>[<a href="#RFC8192" class="xref">RFC8192</a>]</span>, a Network Security Function (NSF) is "a function 
                that is used to ensure integrity, confidentiality, or 
                availability of  network communication; to detect 
                unwanted network activity; or to block, or at least 
                mitigate, the effects of unwanted activity". This document 
                pays special attention to flow-based NSFs that ensure 
                integrity and confidentiality by means of IPsec.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5"> In fact, <span><a href="https://www.rfc-editor.org/rfc/rfc8192#section-3.1.9" class="relref">Section 3.1.9</a> of [<a href="#RFC8192" class="xref">RFC8192</a>]</span> states that
                "there is a need for a controller to create, manage, 
                and distribute various keys to distributed NSFs"; however, 
                "there is a lack of a standard interface to provision 
                and manage security associations". Inspired by the SDN
                paradigm, the I2NSF framework <span>[<a href="#RFC8329" class="xref">RFC8329</a>]</span> 
                defines a centralized entity, the I2NSF Controller, 
                which manages one or multiple NSFs through an 
                I2NSF NSF-Facing Interface. In this 
                document, an architecture is defined for allowing the I2NSF Controller to 
                carry out the key management procedures. More specifically, 
                three YANG data models are defined for the I2NSF NSF-Facing Interface, which
                allows the I2NSF Controller to configure
                and monitor IPsec-enabled, flow-based NSFs.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The IPsec architecture <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> defines
                a clear separation between the processing to provide
                security services to IP packets and the key management
                procedures to establish the IPsec SAs, 
                which allows centralizing the key management procedures 
                in the I2NSF Controller.
                This document considers two typical scenarios to 
                autonomously manage IPsec SAs: gateway-to-gateway and
                host-to-host <span>[<a href="#RFC6071" class="xref">RFC6071</a>]</span>. In these cases,
                hosts, gateways, or both may act as NSFs. Due to its
                complexity, consideration for the host-to-gateway
                scenario is out of scope. The source of this
                complexity comes from the fact that, in this
                scenario,  the host may not be under the control of
                the I2NSF Controller and, therefore, it is not
                configurable. Nevertheless, the I2NSF interfaces
                defined in this document can be considered as a
                 starting
                point to analyze and provide a solution for the
                host-to-gateway scenario.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7"> For the definition of the YANG data models for the I2NSF 
                NSF-Facing Interface, this document considers 
                two general cases, namely:<a href="#section-1-7" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-8">
 <li id="section-1-8.1"> IKE case. The NSF
                        implements the Internet Key Exchange Version 2 (IKEv2)
                        protocol and the IPsec databases: the Security
                        Policy Database (SPD), the Security Association
                        Database (SAD), and the Peer Authorization Database
                        (PAD). The I2NSF Controller is in charge of
                        provisioning the NSF with the required information 
                        in the SPD and PAD (e.g., IKE credentials) and the 
            IKE protocol itself (e.g., parameters for the IKE_SA_INIT
                        negotiation).<a href="#section-1-8.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-8.2"> IKE-less case. The NSF only implements the IPsec
                        databases (no IKE implementation).
                        The I2NSF Controller will provide the required
                        parameters to create valid entries in the SPD and
                        the SAD of the NSF. Therefore, the NSF will only have
                        support for IPsec whereas key management
                        functionality is moved to the I2NSF Controller.<a href="#section-1-8.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-9"> In both cases, a YANG data model for the I2NSF NSF-Facing 
                Interface is required to carry out this provisioning 
                in a secure manner between the I2NSF Controller and the NSF.  
                Using YANG data modeling language version 1.1 <span>[<a href="#RFC7950" class="xref">RFC7950</a>]</span> and 
                based on YANG data models defined in <span>[<a href="#netconf-vpn" class="xref">netconf-vpn</a>]</span> and 
                <span>[<a href="#I-D.tran-ipsecme-yang" class="xref">TRAN-IPSECME-YANG</a>]</span> and the data structures defined 
 in <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> and
                <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>, this document defines the
                required interfaces with a YANG data model for configuration
                and state data for IKE, PAD, SPD, and SAD 
                (see Sections <a href="#ike-common-model" class="xref">5.1</a>, 
                <a href="#ike-case-model" class="xref">5.2</a>, and 
                <a href="#ike-less-model" class="xref">5.3</a>). 
                The proposed YANG data model conforms to the Network Management 
                Datastore Architecture (NMDA) defined in <span>[<a href="#RFC8342" class="xref">RFC8342</a>]</span>.              
                Examples of the usage of these data models can be found in Appendices <a href="#appendix-d" class="xref">A</a>,
                <a href="#appendix-e" class="xref">B</a>,
                and <a href="#appendix-f" class="xref">C</a>.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10"> In summary, the objectives of this document are:<a href="#section-1-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-11.1"> To describe the architecture for I2NSF-based
                        IPsec management, which allows for the
            establishment and management of IPsec
            Security Associations from the I2NSF
            Controller in order to protect specific data
            flows between two flow-based NSFs
            implementing IPsec.<a href="#section-1-11.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-11.2">To map this architecture to the I2NSF
          framework.<a href="#section-1-11.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-11.3">To define the interfaces required to manage
          and monitor the IPsec SAs in the NSF from an
          I2NSF Controller. YANG data models are
                    defined for configuration and state data for
          IPsec and IKEv2 management through the I2NSF
          NSF-Facing Interface. The YANG data models can be
          used via existing protocols, such as the Network Configuration Protocol (NETCONF) 
                    <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> or RESTCONF 
                    <span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span>. Thus, this
                    document defines three YANG modules (see 
          <a href="#models" class="xref">Section 5</a>) but does not define any new
          protocol.<a href="#section-1-11.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="notation">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
                This document uses the terminology described in 
 <span>[<a href="#ITU-T.Y.3300" class="xref">ITU-T.Y.3300</a>]</span>, <span>[<a href="#RFC8192" class="xref">RFC8192</a>]</span>, 
 <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>, <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>, 
 <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>, <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span>, and
 <span>[<a href="#RFC8329" class="xref">RFC8329</a>]</span>.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The following term is defined in <span>[<a href="#ITU-T.Y.3300" class="xref">ITU-T.Y.3300</a>]</span>:<a href="#section-2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-3.1">Software-Defined Networking (SDN)<a href="#section-2-3.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-4">The following terms are defined in <span>[<a href="#RFC8192" class="xref">RFC8192</a>]</span>:<a href="#section-2-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-5.1">Network Security Function (NSF)<a href="#section-2-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-5.2">flow-based NSF<a href="#section-2-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-6">The following terms are defined in <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>:<a href="#section-2-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-7.1">Peer Authorization Database (PAD)<a href="#section-2-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-7.2">Security Association Database (SAD)<a href="#section-2-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-7.3">Security Policy Database (SPD)<a href="#section-2-7.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-8">The following two terms are related or 
         have identical definition/usage in <span>[<a href="#RFC6437" class="xref">RFC6437</a>]</span>:<a href="#section-2-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-9.1">flow<a href="#section-2-9.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-9.2">traffic flow<a href="#section-2-9.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-10">The following term is defined in <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>:<a href="#section-2-10" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-11.1">Internet Key Exchange Version 2 (IKEv2)<a href="#section-2-11.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-2-12">The following terms are defined in <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span>:<a href="#section-2-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2-13.1">configuration data<a href="#section-2-13.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-13.2">configuration datastore<a href="#section-2-13.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-13.3">state data<a href="#section-2-13.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-13.4">startup configuration datastore<a href="#section-2-13.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-2-13.5">running configuration datastore<a href="#section-2-13.5" class="pilcrow">¶</a>
</li>
      </ul>
<section id="section-2.1">
        <h3 id="name-requirements-language">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="cases">
<section id="section-3">
      <h2 id="name-sdn-based-ipsec-management-">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-sdn-based-ipsec-management-" class="section-name selfRef">SDN-Based IPsec Management Description</a>
      </h2>
<p id="section-3-1"> As mentioned in <a href="#intro" class="xref">Section 1</a>, two cases are
            considered, depending on whether the NSF implements IKEv2
            or not: the IKE case and the IKE-less case.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="case1">
<section id="section-3.1">
        <h3 id="name-ike-case-ikev2-ipsec-in-the">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-ike-case-ikev2-ipsec-in-the" class="section-name selfRef">IKE Case: IKEv2/IPsec in the NSF</a>
        </h3>
<p id="section-3.1-1"> In this case, the NSF implements IPsec with
                    IKEv2 support. The I2NSF Controller is in
                    charge of managing and applying IPsec connection
                    information (determining which nodes need to start an
                    IKEv2/IPsec session, identifying the type of traffic to be
                    protected, and deriving and delivering IKEv2 credentials, such
                    as a pre-shared key (PSK), certificates, etc.) and applying
                    other IKEv2 configuration parameters
                    (e.g.,  cryptographic algorithms for establishing an IKEv2
                    SA) to the NSF necessary for the IKEv2 negotiation.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2"> With these entries, the IKEv2 implementation can operate
                    to establish the IPsec SAs. The I2NSF User
                    establishes the IPsec requirements and information about 
                    the endpoints (through the I2NSF 
                    Consumer-Facing Interface
                    <span>[<a href="#RFC8329" class="xref">RFC8329</a>]</span>), and the I2NSF Controller
                    translates these requirements into IKEv2, SPD, and PAD
                    entries that will be installed into the NSF (through the
                    I2NSF NSF-Facing Interface). With that information, 
                    the NSF can just run IKEv2 to establish the required 
                    IPsec SA (when the traffic flow needs protection). 
                    <a href="#fig_nsf-architecture1" class="xref">Figure 1</a>
                    shows the different layers and corresponding functionality.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<span id="name-ike-case-ike-ipsec-in-the-n"></span><div id="fig_nsf-architecture1">
<figure id="figure-1">
          <div class="artwork art-text alignCenter" id="section-3.1-3.1">
<pre>
            +-------------------------------------------+
            |          IPsec Management System          | I2NSF User
            +-------------------------------------------+
                                    |
                                    |  I2NSF Consumer-Facing
                                    |  Interface
            +-------------------------------------------+
            | IKEv2 Configuration, PAD and SPD Entries  | I2NSF
            |               Distribution                | Controller
            +-------------------------------------------+
                                    |
                                    |  I2NSF NSF-Facing
                                    |  Interface
            +-------------------------------------------+
            |   IKEv2  |      IPsec(PAD, SPD)           | Network
            |-------------------------------------------| Security
            |    IPsec Data Protection and Forwarding   | Function
            +-------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-ike-case-ike-ipsec-in-the-n" class="selfRef">IKE Case: IKE/IPsec in the NSF</a>
          </figcaption></figure>
</div>
<p id="section-3.1-4">
                    I2NSF-based IPsec flow protection services provide
                    dynamic and flexible management of IPsec SAs in
                    flow-based NSFs. In order to support this capability
                    in the IKE case, a YANG data model for IKEv2, SPD, and PAD
                    configuration data and for IKEv2 state data 
                    needs to be defined for 
                    the I2NSF NSF-Facing Interface (see <a href="#models" class="xref">Section 5</a>).<a href="#section-3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="case2">
<section id="section-3.2">
        <h3 id="name-ike-less-case-ipsec-no-ikev">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-ike-less-case-ipsec-no-ikev" class="section-name selfRef">IKE-less Case: IPsec (No IKEv2) in the NSF</a>
        </h3>
<p id="section-3.2-1">
                    In this case, the NSF does not deploy IKEv2 and,
                    therefore, the I2NSF Controller has to perform the
                    IKEv2 security functions and management of IPsec SAs by
                    populating and managing the SPD and the SAD.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">
                    As shown in <a href="#fig_nsf-architecture2" class="xref">Figure 2</a>,
                    when an I2NSF User enforces flow-based 
                    protection policies through the Consumer-Facing
                    Interface, the I2NSF Controller translates these
                    requirements into SPD and SAD entries, which are
                    installed in the NSF. PAD entries are not required, since
                    there is no IKEv2 in the NSF.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<span id="name-ike-less-case-ipsec-no-ikev2"></span><div id="fig_nsf-architecture2">
<figure id="figure-2">
          <div class="artwork art-text alignCenter" id="section-3.2-3.1">
<pre>
         +-----------------------------------------+
         |         IPsec Management System         | I2NSF User
         +-----------------------------------------+
                             |
                             |  I2NSF Consumer-Facing Interface
                             |
         +-----------------------------------------+
         |           SPD and SAD Entries           | I2NSF
         |              Distribution               | Controller
         +-----------------------------------------+
                             |
                             |  I2NSF NSF-Facing Interface
                             |
         +-----------------------------------------+
         |             IPsec (SPD, SAD)            | Network
         |-----------------------------------------| Security
         |   IPsec Data Protection and Forwarding  | Function
         +-----------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-ike-less-case-ipsec-no-ikev2" class="selfRef">IKE-less Case: IPsec (No IKEv2) in the NSF</a>
          </figcaption></figure>
</div>
<p id="section-3.2-4">
                    In order to support the IKE-less case, a YANG data model
                    for SPD and SAD configuration data and SAD state data <span class="bcp14">MUST</span> 
                    be defined for the NSF-Facing Interface (see <a href="#models" class="xref">Section 5</a>).<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5"> Specifically, the IKE-less case assumes that the I2NSF
                    Controller has to perform some security functions that
                    IKEv2 typically does, namely (non-exhaustive list):<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-6.1">Initialization Vector (IV) generation<a href="#section-3.2-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-6.2">prevention of counter resets for the same key<a href="#section-3.2-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-6.3">generation of pseudorandom cryptographic
                            keys for the IPsec SAs<a href="#section-3.2-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-6.4">generation of the IPsec SAs when required
                            based on notifications (i.e., sadb-acquire) from
                            the NSF<a href="#section-3.2-6.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-6.5">rekey of the IPsec SAs based on notifications
                            from the NSF (i.e., expire)<a href="#section-3.2-6.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-6.6">NAT traversal discovery and management<a href="#section-3.2-6.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.2-7">Additionally to these functions, another set of tasks
                    must be performed by the I2NSF Controller
                    (non-exhaustive list):<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-8.1">IPsec SA's Security Parameter Index (SPI) random generation<a href="#section-3.2-8.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-8.2">cryptographic algorithm selection<a href="#section-3.2-8.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-8.3">usage of extended sequence numbers<a href="#section-3.2-8.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-8.4">establishment of proper Traffic Selectors<a href="#section-3.2-8.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="comparison">
<section id="section-4">
      <h2 id="name-ike-case-vs-ike-less-case">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-ike-case-vs-ike-less-case" class="section-name selfRef">IKE Case vs. IKE-less Case</a>
      </h2>
<p id="section-4-1">In principle, the IKE case is easier to deploy than the IKE-less
            case because current flow-based NSFs (either hosts or gateways)
            have access to IKEv2 implementations. While gateways typically
            deploy an IKEv2/IPsec implementation, hosts can easily install it.
            As a downside, the NSF needs more resources to use IKEv2, such as
            memory for the IKEv2 implementation and computation, since each
            IPsec Security Association rekeying <span class="bcp14">MAY</span> involve a Diffie-Hellman (DH)
            exchange.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">Alternatively, the IKE-less case benefits the
            deployment in resource-constrained NSFs. Moreover, IKEv2 does not need to be
                performed in gateway-to-gateway and host-to-host scenarios
                under the same I2NSF Controller (see 
                <a href="#appendix-g1" class="xref">Appendix D.1</a>). On the contrary,
                the complexity of creating and managing IPsec SAs is shifted
                to the I2NSF Controller since IKEv2 is not in the
                NSF. As a consequence, this may result in a more complex
                implementation in the controller side in comparison with the
                IKE case.  For example, the I2NSF Controller has to
                deal with the latency existing in the path between the
                I2NSF Controller and the NSF (in order to solve tasks, 
                such as rekey) or creation and installation of new IPsec
                SAs. However, this is not specific to this 
                contribution but a general aspect in any SDN-based
                network. In summary, this complexity may create some
                scalability and performance issues when the number of NSFs
                is high.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">Nevertheless, literature around SDN-based network management
                using a centralized controller (like the I2NSF Controller)
                is aware of scalability and performance issues, and solutions
                have been already provided and discussed (e.g., hierarchical
                controllers, having multiple replicated controllers, dedicated
                high-speed management networks, etc.). In the context of
                I2NSF-based IPsec management, one way to reduce the latency and
                alleviate some performance issues can be to install the
                IPsec policies and IPsec SAs at the same time (proactive mode,
                as described in <a href="#appendix-g1" class="xref">Appendix D.1</a>)
                instead of waiting for notifications (e.g., a 
                sadb-acquire notification received from an NSF requiring a new IPsec SA) 
                to proceed with the IPsec SA installation (reactive mode).
                Another way to reduce the overhead and the potential scalability
                and performance issues in the I2NSF Controller is to apply the
                IKE case described in this document since the IPsec SAs are 
                managed between NSFs without the involvement of the I2NSF
                Controller at all, except by the initial configuration (i.e.,
                IKEv2, PAD, and SPD entries) provided by the I2NSF Controller. 
                Other solutions, such as Controller-IKE 
                <span>[<a href="#I-D.carrel-ipsecme-controller-ike" class="xref">IPSECME-CONTROLLER-IKE</a>]</span>, 
                have proposed that NSFs provide their DH public keys to the 
                I2NSF Controller so that the I2NSF Controller
                distributes all public keys to all peers. All peers can
                calculate a unique pairwise secret for each other peer, and
                there is no inter-NSF messages. A rekey mechanism is 
                further described in 
                <span>[<a href="#I-D.carrel-ipsecme-controller-ike" class="xref">IPSECME-CONTROLLER-IKE</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">In terms of security, the IKE case provides better
            security properties than the IKE-less case, as discussed in 
            <a href="#security" class="xref">Section 7</a>. The main reason is that the
            NSFs generate the session keys and not the
            I2NSF Controller.<a href="#section-4-4" class="pilcrow">¶</a></p>
<div id="rekeying">
<section id="section-4.1">
        <h3 id="name-rekeying-process">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-rekeying-process" class="section-name selfRef">Rekeying Process</a>
        </h3>
<p id="section-4.1-1">Performing a rekey for IPsec SAs is an important
                   operation during the IPsec SAs management. With
                   the YANG data models defined in this
                   document the I2NSF Controller can configure
                   parameters of the rekey process (IKE case) or
                   conduct the rekey process (IKE-less case). 
                   Indeed, depending on the case, the rekey process
                   is different.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">For the IKE case, the rekeying process is carried
                   out by IKEv2, following the information defined
                   in the SPD and SAD (i.e., based on the IPsec SA 
                   lifetime established by the I2NSF Controller using the YANG 
                   data model defined in this document). 
                   Therefore, IPsec connections will live unless something
                   different is required by the I2NSF User or the I2NSF
                   Controller detects something wrong.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">For the IKE-less case, the
                    I2NSF Controller <span class="bcp14">MUST</span> take care
                    of the rekeying process. When the IPsec SA is
                    going to expire (e.g., IPsec SA soft lifetime),
                    it <span class="bcp14">MUST</span> create a new IPsec SA and it <span class="bcp14">MAY</span> remove the
                    old one (e.g., when the lifetime of the old IPsec SA has not been defined). 
                    This rekeying process starts when the
                    I2NSF Controller receives a sadb-expire
                    notification or, on the I2NSF Controller's initiative, 
          based on lifetime state data obtained from the NSF. 
          How the I2NSF Controller implements an algorithm for 
          the rekey process is out of the scope of this document. 
          Nevertheless, an example of how this rekey could be 
          performed is described in <a href="#appendix-g2" class="xref">Appendix D.2</a>.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="restart">
<section id="section-4.2">
        <h3 id="name-nsf-state-loss">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-nsf-state-loss" class="section-name selfRef">NSF State Loss</a>
        </h3>
<p id="section-4.2-1">If one of the NSF restarts, it will lose the
                    IPsec state (affected NSF). By default, the
                    I2NSF 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 the IKE-less case.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2"> In both cases, the I2NSF Controller is aware of
                    the affected NSF (e.g., the NETCONF/TCP connection is
                    broken with the affected NSF, the I2NSF Controller is
                    receiving a sadb-bad-spi notification from a particular
                    NSF, etc.). Moreover, the I2NSF Controller keeps 
                    a list of NSFs that have IPsec SAs with the
                    affected NSF. Therefore, it knows the affected IPsec
                    SAs.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">In the IKE case, the I2NSF Controller may need
                to configure the affected NSF with the new IKEv2,
                SPD, and PAD information.  Alternatively, IKEv2
                 configuration <span class="bcp14">MAY</span> be made
                  permanent between NSF reboots without
                  compromising security by means of the startup
                  configuration datastore in the NSF. This
                  way, each time an NSF reboots, it will use that
                  configuration for each rebooting. It would imply
                  avoiding contact with the I2NSF Controller. 
                  Finally, the I2NSF Controller 
                  may also need to send new parameters
                (e.g., a new fresh PSK for authentication) to the NSFs
                that had IKEv2 SAs and IPsec SAs with the affected
                NSF.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">In the IKE-less case, the I2NSF Controller <span class="bcp14">SHOULD</span> delete
                   the old IPsec SAs in the non-failed nodes established with
                   the affected NSF. Once the affected node restarts, the I2NSF
                   Controller <span class="bcp14">MUST</span> take the necessary actions to reestablish
                   IPsec-protected communication between the failed node and
                   those others having IPsec SAs with the affected NSF. 
                   How the I2NSF Controller implements an algorithm for
                   managing a potential NSF state loss is out of the scope of
                   this document. Nevertheless, an example of how this could be
                   performed is described in <a href="#appendix-g3" class="xref">Appendix D.3</a>.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nat-traversal">
<section id="section-4.3">
        <h3 id="name-nat-traversal">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-nat-traversal" class="section-name selfRef">NAT Traversal</a>
        </h3>
<p id="section-4.3-1">In the IKE case, IKEv2 already provides a mechanism
                    to detect whether some of the peers or both are located
                    behind a NAT. In this case, UDP or TCP
encapsulation for Encapsulating Security Payload (ESP) packets <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span> <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span> is required.
          Note that IPsec transport mode <span class="bcp14">MUST NOT</span> be used in this specification
          when NAT is required.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">In the IKE-less case, the NSF does not have the assistance
                   of the IKEv2 implementation to detect if it is located
                   behind a NAT. If the NSF does not have any other mechanism
                   to detect this situation, the I2NSF Controller <span class="bcp14">SHOULD</span>
                   implement a mechanism to detect that case. The SDN paradigm
                   generally assumes the I2NSF Controller has a view of the
                   network under its control. This view is built either by
                   requesting information from the NSFs under its control or
                   information pushed from the NSFs to the I2NSF Controller.
                   Based on this information, the I2NSF Controller <span class="bcp14">MAY</span> 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 encapsulation of ESP packets 
                   <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span> <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span>. 
                   The interface for discovering if the NSF 
                   is behind a NAT is out of scope of this document.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">If the I2NSF Controller does not have any mechanism to know 
                    whether a host is behind a NAT or not, then the IKE case
                    <span class="bcp14">MUST</span> be used and not the IKE-less case.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="nsf-discovery">
<section id="section-4.4">
        <h3 id="name-nsf-registration-and-discov">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-nsf-registration-and-discov" class="section-name selfRef">NSF Registration and Discovery</a>
        </h3>
<p id="section-4.4-1">NSF registration refers to the process of providing the
                   I2NSF Controller information about a valid NSF, such as
                   certificate, IP address, etc. This information is
                   incorporated in a list of NSFs under its control.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">The assumption in this document is that, for both
                   cases, before an NSF can operate in this system, it <span class="bcp14">MUST</span>
                   be registered in the I2NSF Controller. In this way, when 
                   the NSF starts and establishes a connection to the I2NSF
                   Controller, it knows that the NSF is valid for joining the
                   system.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">Either during this registration process or when the
                   NSF connects with the I2NSF Controller, the I2NSF
                   Controller <span class="bcp14">MUST</span> discover certain capabilities of this
                   NSF, such as what are the cryptographic suites supported,
                   the authentication method, the support of the IKE case and/or
                   the IKE-less case, etc.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">The registration and discovery processes are out of
                   the scope of this document.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="models">
<section id="section-5">
      <h2 id="name-yang-configuration-data-mod">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-yang-configuration-data-mod" class="section-name selfRef">YANG Configuration Data Models</a>
      </h2>
<p id="section-5-1"> In order to support the IKE and IKE-less cases,
              models are provided for the different parameters and
              values that must be configured to manage IPsec SAs.
              Specifically, the IKE case requires modeling IKEv2
              configuration parameters, SPD and PAD, 
                while the IKE-less case requires configuration
                YANG data models for the
                SPD and SAD. Three modules have been defined: ietf-i2nsf-ikec 
                (<a href="#ike-common-model" class="xref">Section 5.1</a>, common to both cases),
                ietf-i2nsf-ike  (<a href="#ike-case-model" class="xref">Section 5.2</a>, IKE case), and
                ietf-i2nsf-ikeless (<a href="#ike-less-model" class="xref">Section 5.3</a>, IKE-less case).
                Since the module ietf-i2nsf-ikec has only typedef and
                groupings common to the other modules, a
                simplified view of the ietf-i2nsf-ike and ietf-i2nsf-ikeless
                modules is shown.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="ike-common-model">
<section id="section-5.1">
        <h3 id="name-the-ietf-i2nsf-ikec-module">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-the-ietf-i2nsf-ikec-module" class="section-name selfRef">The 'ietf-i2nsf-ikec' Module</a>
        </h3>
<div id="common-overview">
<section id="section-5.1.1">
          <h4 id="name-data-model-overview">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-data-model-overview" class="section-name selfRef">Data Model Overview</a>
          </h4>
<p id="section-5.1.1-1">The module ietf-i2nsf-ikec only has definitions of
                data types (typedef) and groupings that are common
                to the other modules.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="common-module">
<section id="section-5.1.2">
          <h4 id="name-yang-module">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-yang-module" class="section-name selfRef">YANG Module</a>
          </h4>
<p id="section-5.1.2-1">
                      This module has normative references to <span>[<a href="#RFC3947" class="xref">RFC3947</a>]</span>, <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>, <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span>, <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span>, <span>[<a href="#RFC8221" class="xref">RFC8221</a>]</span>, <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span>,  <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span>, <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>, <span>[<a href="#IANA-Protocols-Number" class="xref">IANA-Protocols-Number</a>]</span>, <span>[<a href="#IKEv2-Parameters" class="xref">IKEv2-Parameters</a>]</span>, <span>[<a href="#IKEv2-Transform-Type-1" class="xref">IKEv2-Transform-Type-1</a>]</span>, and <span>[<a href="#IKEv2-Transform-Type-3" class="xref">IKEv2-Transform-Type-3</a>]</span>.<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
<div id="section-5.1.2-2">
<pre class="sourcecode lang-yang">&lt;CODE BEGINS&gt; file "ietf-i2nsf-ikec@2021-07-14.yang"


module ietf-i2nsf-ikec {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
  prefix nsfikec;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types.";
  }

  organization
    "IETF I2NSF Working Group";
  contact
    "WG Web:  &lt;https://datatracker.ietf.org/wg/i2nsf/&gt;
     WG List: &lt;mailto:i2nsf@ietf.org&gt;

     Author: Rafael Marin-Lopez
               &lt;mailto:rafa@um.es&gt;

     Author: Gabriel Lopez-Millan
               &lt;mailto:gabilm@um.es&gt;

     Author: Fernando Pereniguez-Garcia
               &lt;mailto:fernando.pereniguez@cud.upct.es&gt;
    ";
  description
    "Common data model for the IKE and IKE-less cases
     defined by the SDN-based IPsec flow protection service.

     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.

     Copyright (c) 2021 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 9061; see
     the RFC itself for full legal notices.";

  revision 2021-07-14 {
    description
      "Initial version.";
    reference
      "RFC 9061: A YANG Data Model for IPsec Flow Protection
                 Based on Software-Defined Networking (SDN).";
  }

  typedef encr-alg-t {
    type uint16;
    description
      "The encryption algorithm is specified with a 16-bit
       number extracted from the IANA registry.  The acceptable
       values MUST follow the requirement levels for
       encryption algorithms for ESP and IKEv2.";
    reference
      "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
             IKEv2 Transform Attribute Types, 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)
       RFC 8247: Algorithm Implementation Requirements and Usage
                 Guidance for the Internet Key Exchange Protocol
                 Version 2 (IKEv2).";
  }

  typedef intr-alg-t {
    type uint16;
    description
      "The integrity algorithm is specified with a 16-bit
       number extracted from the IANA registry.
       The acceptable values MUST follow the requirement
       levels for integrity algorithms for ESP and IKEv2.";
    reference
      "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
             IKEv2 Transform Attribute Types, 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)
       RFC 8247: Algorithm Implementation Requirements and Usage
                 Guidance for the Internet Key Exchange Protocol
                 Version 2 (IKEv2).";
  }

  typedef ipsec-mode {
    type enumeration {
      enum transport {
        description
          "IPsec transport mode.  No Network Address
           Translation (NAT) support.";
      }
      enum tunnel {
        description
          "IPsec tunnel mode.";
      }
    }
    description
      "Type definition of IPsec mode: transport or
       tunnel.";
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 3.2.";
  }

  typedef esp-encap {
    type enumeration {
      enum espintcp {
        description
          "ESP in TCP encapsulation.";
        reference
          "RFC 8229: TCP Encapsulation of IKE and
                     IPsec Packets.";
      }
      enum espinudp {
        description
          "ESP in UDP encapsulation.";
        reference
          "RFC 3948: UDP Encapsulation of IPsec ESP
                     Packets.";
      }
      enum none {
        description
          "No ESP encapsulation.";
      }
    }
    description
      "Types of ESP encapsulation when Network Address
       Translation (NAT) may be present between two NSFs.";
    reference
      "RFC 8229: TCP Encapsulation of IKE and IPsec Packets
       RFC 3948: UDP Encapsulation of IPsec ESP Packets.";
  }

  typedef ipsec-protocol-params {
    type enumeration {
      enum esp {
        description
          "IPsec ESP protocol.";
      }
    }
    description
      "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
          "Terminates the IPsec SA and allows the
           packets through.";
      }
      enum terminate-hold {
        description
          "Terminates the IPsec SA and drops the
           packets.";
      }
      enum replace {
        description
          "Replaces the IPsec SA with a new one:
           rekey.";
      }
    }
    description
      "When the lifetime of an IPsec SA expires, an action
       needs to be performed for the IPsec SA that
       reached the lifetime.  There are three possible
       options: terminate-clear, terminate-hold, and
       replace.";
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 4.5.";
  }

  typedef ipsec-traffic-direction {
    type enumeration {
      enum inbound {
        description
          "Inbound traffic.";
      }
      enum outbound {
        description
          "Outbound traffic.";
      }
    }
    description
      "IPsec traffic direction is defined in
       two directions: inbound and outbound.
       From an NSF perspective, inbound and
       outbound are defined as mentioned
       in Section 3.1 in RFC 4301.";
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 3.1.";
  }

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

  typedef ipsec-inner-protocol {
    type union {
      type uint8;
      type enumeration {
        enum any {
          value 256;
          description
            "Any IP protocol number value.";
        }
      }
    }
    default "any";
    description
      "IPsec protection can be applied to specific IP
       traffic and Layer 4 traffic (TCP, UDP, SCTP, etc.)
       or ANY protocol in the IP packet payload.
       The IP protocol number is specified with a uint8
       or ANY defining an enumerate with value 256 to
       indicate the protocol number.  Note that in case
       of IPv6, the protocol in the IP packet payload
       is indicated in the Next Header field of the IPv6
       packet.";
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 4.4.1.1
       IANA: Protocol Numbers.";
  }

  grouping encap {
    description
      "This group of nodes allows defining of the type of
       encapsulation in case NAT traversal is
       required and includes port information.";
    leaf espencap {
      type esp-encap;
      default "none";
      description
        "ESP in TCP, ESP in UDP, or ESP in TLS.";
    }
    leaf sport {
      type inet:port-number;
      default "4500";
      description
        "Encapsulation source port.";
    }
    leaf dport {
      type inet:port-number;
      default "4500";
      description
        "Encapsulation destination port.";
    }
    leaf-list oaddr {
      type inet:ip-address;
      description
        "If required, this is the original address that
         was used before NAT was applied over the packet.";
    }
    reference
      "RFC 3947: Negotiation of NAT-Traversal in the IKE
       RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
  }

  grouping lifetime {
    description
      "Different lifetime values limited to an IPsec SA.";
    leaf time {
      type uint32;
      units "seconds";
      default "0";
      description
        "Time in seconds since the IPsec SA was added.
         For example, if this value is 180 seconds, it
         means the IPsec SA expires in 180 seconds since
         it was added.  The value 0 implies infinite.";
    }
    leaf bytes {
      type uint64;
      default "0";
      description
        "If the IPsec SA processes the number of bytes
         expressed in this leaf, the IPsec SA expires and
         SHOULD be rekeyed.  The value 0 implies
         infinite.";
    }
    leaf packets {
      type uint32;
      default "0";
      description
        "If the IPsec SA processes the number of packets
         expressed in this leaf, the IPsec SA expires and
         SHOULD be rekeyed.  The value 0 implies
         infinite.";
    }
    leaf idle {
      type uint32;
      units "seconds";
      default "0";
      description
        "When an NSF stores an IPsec SA, it
         consumes system resources.  For an idle IPsec SA, 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
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 4.4.2.1.";
  }

  grouping port-range {
    description
      "This grouping defines a port range, such as that
       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;
      must '. &gt;= ../start' {
        error-message
          "The end port number MUST be equal or greater
           than the start port number.";
      }
      description
        "End port number.  To express a single port, set
         the same value as start and end.";
    }
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 4.4.1.2.";
  }

  grouping tunnel-grouping {
    description
      "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 {
      type inet:ip-address;
      mandatory true;
      description
        "Local IP address' tunnel endpoint.";
    }
    leaf remote {
      type inet:ip-address;
      mandatory true;
      description
        "Remote IP address' tunnel endpoint.";
    }
    leaf df-bit {
      type enumeration {
        enum clear {
          description
            "Disable the Don't Fragment (DF) bit
             in 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
        "Allow configuring the DF bit when encapsulating
         tunnel mode IPsec traffic.  RFC 4301 describes
         three options to handle the DF bit during
         tunnel encapsulation: clear, set, and copy from
         the inner IP header.  This MUST be ignored or
         has no meaning when the local/remote
         IP addresses are IPv6 addresses.";
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 8.1.";
    }
    leaf bypass-dscp {
      type boolean;
      default "true";
      description
        "If true, to copy the Differentiated Services Code
         Point (DSCP) value from inner header to outer header.
         If false, to map DSCP values
         from an inner header to values in an outer header
         following ../dscp-mapping.";
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.1.2.";
    }
    list dscp-mapping {
      must '../bypass-dscp = "false"';
      key "id";
      ordered-by user;
      leaf id {
        type uint8;
        description
          "The index of list with the
           different mappings.";
      }
      leaf inner-dscp {
        type inet:dscp;
        description
          "The DSCP value of the inner IP packet.  If this
           leaf is not defined, it means ANY inner DSCP value.";
      }
      leaf outer-dscp {
        type inet:dscp;
        default "0";
        description
          "The DSCP value of the outer IP packet.";
      }
      description
        "A list that represents an array with the mapping from the
         inner DSCP value to outer DSCP value when bypass-dscp is
         false.  To express a default mapping in the list where any
         other inner dscp value is not matching a node in the list,
         a new node has to be included at the end of the list where
         the leaf inner-dscp is not defined (ANY) and the leaf
         outer-dscp includes the value of the mapping.  If there is
         no value set in the leaf outer-dscp, the default value for
         this leaf is 0.";
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.1.2 and Appendix C.";
    }
  }

  grouping selector-grouping {
    description
      "This grouping contains the definition of a Traffic
       Selector, which is used in the IPsec policies and
       IPsec SAs.";
    leaf local-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "Local IP address prefix.";
    }
    leaf remote-prefix {
      type inet:ip-prefix;
      mandatory true;
      description
        "Remote IP address prefix.";
    }
    leaf inner-protocol {
      type ipsec-inner-protocol;
      default "any";
      description
        "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 inner
         protocol is ICMP, this 16-bit value
         represents code and type.
         If this list is not defined,
         it is assumed that start and
         end are 0 by default (any port).";
    }
    list remote-ports {
      key "start end";
      uses port-range;
      description
        "List of remote ports. When the upper layer
         protocol is ICMP, this 16-bit value represents
         code and type.  If this list is not defined,
         it is assumed that start and end are 0 by
         default (any port).";
    }
    reference
      "RFC 4301: Security Architecture for the Internet Protocol,
                 Section 4.4.1.2.";
  }

  grouping ipsec-policy-grouping {
    description
      "Holds configuration information for an IPsec SPD
       entry.";
    leaf anti-replay-window-size {
      type uint32;
      default "64";
      description
        "To set the anti-replay window size.
         The default value is set
         to 64, following the recommendation in RFC 4303.";
      reference
        "RFC 4303: IP Encapsulating Security Payload (ESP),
                   Section 3.4.3.";
    }
    container traffic-selector {
      description
        "Packets are selected for
         processing actions based on Traffic Selector
         values, which refer to IP and inner protocol
         header information.";
      uses selector-grouping;
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.4.1.";
    }
    container processing-info {
      description
        "SPD processing.  If the required processing
         action is protect, it contains the required
         information to process the packet.";
      leaf action {
        type ipsec-spd-action;
        default "discard";
        description
          "If bypass or discard, container
           ipsec-sa-cfg is empty.";
      }
      container ipsec-sa-cfg {
        when "../action = 'protect'";
        description
          "IPsec SA configuration included in the SPD
           entry.";
        leaf pfp-flag {
          type boolean;
          default "false";
          description
            "Each selector has a Populate From
             Packet (PFP) flag.  If asserted for a
             given selector X, the flag indicates
             that the IPsec SA 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 ext-seq-num {
          type boolean;
          default "false";
          description
            "True if this IPsec SA is using extended
             sequence numbers.  If true, the 64-bit
             extended sequence number counter is used;
             if false, the normal 32-bit sequence
             number counter is used.";
        }
        leaf seq-overflow {
          type boolean;
          default "false";
          description
            "The flag indicating whether
             overflow of the sequence number
             counter should prevent transmission
             of 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 (leaf
             esp-algorithms/encryption/algorithm-type),
             this flag MUST be false.  Setting this
             flag to true is strongly discouraged.";
        }
        leaf stateful-frag-check {
          type boolean;
          default "false";
          description
            "Indicates whether (true) or not (false)
             stateful fragment checking applies to
             the IPsec SA to be created.";
        }
        leaf mode {
          type ipsec-mode;
          default "transport";
          description
            "IPsec SA has to be processed in
             transport or tunnel mode.";
        }
        leaf protocol-parameters {
          type ipsec-protocol-params;
          default "esp";
          description
            "Security protocol of the IPsec SA.
             Only ESP is supported, but it could be
             extended in the future.";
        }
        container esp-algorithms {
          when "../protocol-parameters = 'esp'";
          description
            "Configuration of Encapsulating
             Security Payload (ESP) parameters and
             algorithms.";
          leaf-list integrity {
            type intr-alg-t;
            default "0";
            ordered-by user;
            description
              "Configuration of ESP authentication
               based on the specified integrity
               algorithm.  With AEAD encryption
               algorithms, the integrity node is
               not used.";
            reference
              "RFC 4303: IP Encapsulating Security Payload (ESP),
                         Section 3.2.";
          }
          list encryption {
            key "id";
            ordered-by user;
            leaf id {
              type uint16;
              description
                "An identifier that unequivocally identifies each
                 entry of the list, i.e., an encryption algorithm
                 and its key length (if required).";
            }
            leaf algorithm-type {
              type encr-alg-t;
              default "20";
              description
                "Default value 20 (ENCR_AES_GCM_16).";
            }
            leaf key-length {
              type uint16;
              default "128";
              description
                "By default, key length is 128
                 bits.";
            }
            description
              "Encryption or AEAD algorithm for the
               IPsec 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.  In case the list
               is empty, then no encryption algorithm
               is applied (NULL).";
            reference
              "RFC 4303: IP Encapsulating Security Payload (ESP),
                         Section 3.2.";
          }
          leaf tfc-pad {
            type boolean;
            default "false";
            description
              "If Traffic Flow Confidentiality
               (TFC) padding for ESP encryption
               can be used (true) or not (false).";
            reference
              "RFC 4303: IP Encapsulating Security Payload (ESP),
                         Section 2.7.";
          }
          reference
            "RFC 4303: IP Encapsulating Security Payload (ESP).";
        }
        container tunnel {
          when "../mode = 'tunnel'";
          uses tunnel-grouping;
          description
            "IPsec tunnel endpoints definition.";
        }
      }
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.1.2.";
    }
  }
}

&lt;CODE ENDS&gt;</pre><a href="#section-5.1.2-2" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="ike-case-model">
<section id="section-5.2">
        <h3 id="name-the-ietf-i2nsf-ike-module">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-the-ietf-i2nsf-ike-module" class="section-name selfRef">The 'ietf-i2nsf-ike' Module</a>
        </h3>
<p id="section-5.2-1">In this section, the YANG module for the IKE case is described.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<div id="ike-overview">
<section id="section-5.2.1">
          <h4 id="name-data-model-overview-2">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-data-model-overview-2" class="section-name selfRef">Data Model Overview</a>
          </h4>
<p id="section-5.2.1-1">The model related to IKEv2 has been extracted from
                  reading the IKEv2 standard in 
                  <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span> and observing some open
                  source implementations, such as strongSwan 
                  <span>[<a href="#strongswan" class="xref">strongswan</a>]</span> or Libreswan 
                  <span>[<a href="#libreswan" class="xref">libreswan</a>]</span>.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">The definition of the PAD model has been
                extracted from the specification in 
                <span><a href="https://www.rfc-editor.org/rfc/rfc4301#section-4.4.3" class="relref">Section 4.4.3</a> of [<a href="#RFC4301" class="xref">RFC4301</a>]</span>. (Note that many 
                implementations integrate PAD configuration as part
                of the IKEv2 configuration.)<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3"> The definition of the SPD model has been
                mainly extracted from the specification in Section
                <a href="https://www.rfc-editor.org/rfc/rfc4301#section-4.4.1" class="relref">4.4.1</a> and Appendix <a href="https://www.rfc-editor.org/rfc/rfc4301#appendix-D" class="relref">D</a> of <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<p id="section-5.2.1-4"> The YANG data model for the IKE case is defined by the module "ietf-i2nsf-ike". Its structure is depicted in the following diagram, using the notation syntax for YANG tree diagrams <span>[<a href="#RFC8340" class="xref">RFC8340</a>]</span>.<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
<div id="section-5.2.1-5">
<pre class="sourcecode lang-yangtree">
module: ietf-i2nsf-ike
  +--rw ipsec-ike
    +--rw pad
    |  +--rw pad-entry* [name]
    |     +--rw name                           string
    |     +--rw (identity)
    |     |  +--:(ipv4-address)
    |     |  |  +--rw ipv4-address?            inet:ipv4-address
    |     |  +--:(ipv6-address)
    |     |  |  +--rw ipv6-address?            inet:ipv6-address
    |     |  +--:(fqdn-string)
    |     |  |  +--rw fqdn-string?             inet:domain-name
    |     |  +--:(rfc822-address-string)
    |     |  |  +--rw rfc822-address-string?   string
    |     |  +--:(dnx509)
    |     |  |  +--rw dnx509?                  binary
    |     |  +--:(gnx509)
    |     |  |  +--rw gnx509?                  binary
    |     |  +--:(id-key)
    |     |  |  +--rw id-key?                  binary
    |     |  +--:(id-null)
    |     |     +--rw id-null?                 empty
    |     +--rw auth-protocol?                 auth-protocol-type
    |     +--rw peer-authentication
    |        +--rw auth-method?         auth-method-type
    |        +--rw eap-method
    |        |  +--rw eap-type    uint64
    |        +--rw pre-shared
    |        |  +--rw secret?   yang:hex-string
    |        +--rw digital-signature
    |           +--rw ds-algorithm?           uint8
    |           +--rw (public-key)?
    |           |  +--:(raw-public-key)
    |           |  |  +--rw raw-public-key?   binary
    |           |  +--:(cert-data)
    |           |     +--rw cert-data?        binary
    |           +--rw private-key?            binary
    |           +--rw ca-data*                binary
    |           +--rw crl-data?               binary
    |           +--rw crl-uri?                inet:uri
    |           +--rw oscp-uri?               inet:uri
    +--rw conn-entry* [name]
    |  +--rw name                             string
    |  +--rw autostartup?                     autostartup-type
    |  +--rw initial-contact?                 boolean
    |  +--rw version?                         auth-protocol-type
    |  +--rw fragmentation
    |  |  +--rw enabled?   boolean
    |  |  +--rw mtu?      uint16
    |  +--rw ike-sa-lifetime-soft
    |  |  +--rw rekey-time?    uint32
    |  |  +--rw reauth-time?   uint32
    |  +--rw ike-sa-lifetime-hard
    |  |  +--rw over-time?   uint32
    |  +--rw ike-sa-intr-alg*  nsfikec:intr-alg-t
    |  +--rw ike-sa-encr-alg* [id]
    |  |  +--rw id                uint16
    |  |  +--rw algorithm-type?   nsfikec:encr-alg-t
    |  |  +--rw key-length?       uint16
    |  +--rw dh-group?                            fs-group
    |  +--rw half-open-ike-sa-timer?              uint32
    |  +--rw half-open-ike-sa-cookie-threshold?   uint32
    |  +--rw local
    |  |  +--rw local-pad-entry-name    string
    |  +--rw remote
    |  |  +--rw remote-pad-entry-name    string
    |  +--rw encapsulation-type
    |  |  +--rw espencap?   esp-encap
    |  |  +--rw sport?      inet:port-number
    |  |  +--rw dport?      inet:port-number
    |  |  +--rw oaddr*      inet:ip-address
    |  +--rw spd
    |  |  +--rw spd-entry* [name]
    |  |    +--rw name                   string
    |  |    +--rw ipsec-policy-config
    |  |      +--rw anti-replay-window-size?   uint32
    |  |      +--rw traffic-selector
    |  |      |  +--rw local-prefix      inet:ip-prefix
    |  |      |  +--rw remote-prefix     inet:ip-prefix
    |  |      |  +--rw inner-protocol?   ipsec-inner-protocol
    |  |      |  +--rw local-ports* [start end]
    |  |      |  |  +--rw start    inet:port-number
    |  |      |  |  +--rw end      inet:port-number
    |  |      |  +--rw remote-ports* [start end]
    |  |      |     +--rw start    inet:port-number
    |  |      |     +--rw end      inet:port-number
    |  |      +--rw processing-info
    |  |        +--rw action?         ipsec-spd-action
    |  |        +--rw ipsec-sa-cfg
    |  |         +--rw pfp-flag?              boolean
    |  |         +--rw ext-seq-num?           boolean
    |  |         +--rw seq-overflow?          boolean
    |  |         +--rw stateful-frag-check?   boolean
    |  |         +--rw mode?                  ipsec-mode
    |  |         +--rw protocol-parameters? ipsec-protocol-params
    |  |              +--rw esp-algorithms
    |  |              |  +--rw integrity*    intr-alg-t
    |  |              |  +--rw encryption* [id]
    |  |              |  |  +--rw id                uint16
    |  |              |  |  +--rw algorithm-type?   encr-alg-t
    |  |              |  |  +--rw key-length?       uint16
    |  |              |  +--rw tfc-pad?      boolean
    |  |              +--rw tunnel
    |  |                 +--rw local           inet:ip-address
    |  |                 +--rw remote          inet:ip-address
    |  |                 +--rw df-bit?         enumeration
    |  |                 +--rw bypass-dscp?    boolean
    |  |                 +--rw dscp-mapping* [id]
    |  |                    +--rw id            uint8
    |  |                    +--rw inner-dscp?   inet:dscp
    |  |                    +--rw outer-dscp?   inet:dscp
    |  +--rw child-sa-info
    |  |  +--rw fs-groups*                fs-group
    |  |  +--rw child-sa-lifetime-soft
    |  |  |  +--rw time?      uint32
    |  |  |  +--rw bytes?     yang:counter64
    |  |  |  +--rw packets?   uint32
    |  |  |  +--rw idle?      uint32
    |  |  |  +--rw action?    nsfikec:lifetime-action
    |  |  +--rw child-sa-lifetime-hard
    |  |     +--rw time?      uint32
    |  |     +--rw bytes?     yang:counter64
    |  |     +--rw packets?   uint32
    |  |     +--rw idle?      uint32
    |  +--ro state
    |     +--ro initiator?             boolean
    |     +--ro initiator-ikesa-spi?   ike-spi
    |     +--ro responder-ikesa-spi?   ike-spi
    |     +--ro nat-local?             boolean
    |     +--ro nat-remote?            boolean
    |     +--ro encapsulation-type
    |     |  +--ro espencap?   esp-encap
    |     |  +--ro sport?      inet:port-number
    |     |  +--ro dport?      inet:port-number
    |     |  +--ro oaddr*      inet:ip-address
    |     +--ro established?           uint64
    |     +--ro current-rekey-time?    uint64
    |     +--ro current-reauth-time?   uint64
    +--ro number-ike-sas
        +--ro total?               yang:gauge64
        +--ro half-open?           yang:gauge64
        +--ro half-open-cookies?   yang:gauge64
</pre><a href="#section-5.2.1-5" class="pilcrow">¶</a>
</div>
<p id="section-5.2.1-6">
                     The YANG data model consists of a unique
                    "ipsec-ike"
                     container defined as follows. Firstly, it
                     contains a "pad" container that serves to
                     configure the Peer Authentication Database 
                     with authentication information about local 
                     and remote peers (NSFs). More precisely, it
                     consists of a list of entries, each one
                     indicating the identity, authentication method,
                     and credentials that a particular peer (local or
                     remote) will use. Therefore, each entry contains
                     identity, authentication information, and
                     credentials of either the local NSF or the
                     remote NSF. As a consequence, the I2NF Controller can
                     store identity, authentication information, and
                     credentials for the local NSF and the remote
                     NSF.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
<p id="section-5.2.1-7"> Next, a list "conn-entry" is defined with
                     information about the different IKE connections
                     a peer can maintain with others. Each connection
                     entry is composed of a wide number of parameters
                     to configure different aspects of a particular
                     IKE connection between two peers: local and
                     remote peer authentication information, IKE SA
                     configuration (soft and hard lifetimes,
                     cryptographic algorithms, etc.), a list of IPsec
                     policies describing the type of network traffic
                     to be secured (local/remote subnet and ports,
                     etc.) and how it must be protected (ESP,
                     tunnel/transport, cryptographic algorithms,
                     etc.), Child SA configuration (soft and hard
                     lifetimes), and state information of the IKE
                     connection (SPIs, usage of NAT, current
                     expiration times, etc.).<a href="#section-5.2.1-7" class="pilcrow">¶</a></p>
<p id="section-5.2.1-8">Lastly, the "ipsec-ike" container declares a
                    "number-ike-sas" container to specify state
                    information reported by the IKE software related
                    to the amount of IKE connections established.<a href="#section-5.2.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ike-example">
<section id="section-5.2.2">
          <h4 id="name-example-usage">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-example-usage" class="section-name selfRef">Example Usage</a>
          </h4>
<p id="section-5.2.2-1"><a href="#appendix-d" class="xref">Appendix A</a> shows an example
               of IKE case configuration for an NSF, in tunnel
               mode (gateway-to-gateway), with NSF
               authentication based on X.509 certificates.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ike-module">
<section id="section-5.2.3">
          <h4 id="name-yang-module-2">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-yang-module-2" class="section-name selfRef">YANG Module</a>
          </h4>
<p id="section-5.2.3-1">This YANG module has normative references to <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>, <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>, <span>[<a href="#RFC5915" class="xref">RFC5915</a>]</span>, <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>, <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>, <span>[<a href="#RFC7383" class="xref">RFC7383</a>]</span>, <span>[<a href="#RFC7427" class="xref">RFC7427</a>]</span>, <span>[<a href="#RFC7619" class="xref">RFC7619</a>]</span>, <span>[<a href="#RFC8017" class="xref">RFC8017</a>]</span>, <span>[<a href="#ITU-T.X.690" class="xref">ITU-T.X.690</a>]</span>, <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>, <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span>, <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span>, <span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span>, <span>[<a href="#IKEv2-Auth-Method" class="xref">IKEv2-Auth-Method</a>]</span>, <span>[<a href="#IKEv2-Transform-Type-4" class="xref">IKEv2-Transform-Type-4</a>]</span>, <span>[<a href="#IKEv2-Parameters" class="xref">IKEv2-Parameters</a>]</span>, and <span>[<a href="#IANA-Method-Type" class="xref">IANA-Method-Type</a>]</span>.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<div id="section-5.2.3-2">
<pre class="sourcecode lang-yang">&lt;CODE BEGINS&gt; file "ietf-i2nsf-ike@2021-07-14.yang"


module ietf-i2nsf-ike {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
  prefix nsfike;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types.";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types.";
  }
  import ietf-i2nsf-ikec {
    prefix nsfikec;
    reference
      "RFC 9061: A YANG Data Model for IPsec Flow Protection
                 Based on Software-Defined Networking (SDN).";
  }
  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control
                 Model.";
  }

  organization
    "IETF I2NSF Working Group";
  contact
    "WG Web:  &lt;https://datatracker.ietf.org/wg/i2nsf/&gt;
     WG List: &lt;mailto:i2nsf@ietf.org&gt;

     Author: Rafael Marin-Lopez
               &lt;mailto:rafa@um.es&gt;

     Author: Gabriel Lopez-Millan
               &lt;mailto:gabilm@um.es&gt;

     Author: Fernando Pereniguez-Garcia
               &lt;mailto:fernando.pereniguez@cud.upct.es&gt;
    ";
  description
    "This module contains the IPsec IKE case model for the SDN-based
     IPsec flow protection service.

     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.

     Copyright (c) 2021 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
     (http://trustee.ietf.org/license-info).

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

  revision 2021-07-14 {
    description
      "Initial version.";
    reference
      "RFC 9061: A YANG Data Model for IPsec Flow Protection
                 Based on Software-Defined Networking (SDN).";
  }

  typedef ike-spi {
    type uint64 {
      range "0..max";
    }
    description
      "Security Parameter Index (SPI)'s IKE SA.";
    reference
      "RFC 7296: Internet Key Exchange Protocol Version 2
                 (IKEv2), Section 2.6.";
  }

  typedef autostartup-type {
    type enumeration {
      enum add {
        description
          "IKE/IPsec configuration is only loaded into
           IKE implementation, but IKE/IPsec SA is not
           started.";
      }
      enum on-demand {
        description
          "IKE/IPsec configuration is loaded
           into IKE implementation.  The IPsec policies
           are transferred to the NSF, but the
           IPsec SAs are not established immediately.
           The IKE implementation will negotiate the
           IPsec SAs when they are required
           (i.e., through an ACQUIRE notification).";
      }
      enum start {
        description
          "IKE/IPsec configuration is loaded
           and transferred to the NSF's kernel, and the
           IKEv2-based IPsec SAs are established
           immediately without waiting for any packet.";
      }
    }
    description
      "Different policies to set IPsec SA configuration
       into NSF's kernel when IKEv2 implementation has
       started.";
  }

  typedef fs-group {
    type uint16;
    description
      "DH groups for IKE and IPsec SA rekey.";
    reference
      "IANA: Internet Key Exchange Version 2 (IKEv2) Parameters,
             IKEv2 Transform Attribute Types, Transform Type 4 -
             Diffie-Hellman Group Transform IDs
       RFC 7296: Internet Key Exchange Protocol Version 2
                 (IKEv2), Section 3.3.2.";
  }

  typedef auth-protocol-type {
    type enumeration {
      enum ikev2 {
        value 2;
        description
          "IKEv2 authentication protocol.  It is the
           only one defined right now.  An enum is
           used for further extensibility.";
      }
    }
    description
      "IKE authentication protocol version specified in the
       Peer Authorization Database (PAD).  It is defined as
       enumerated to allow new IKE versions in the
       future.";
    reference
      "RFC 7296: Internet Key Exchange Protocol Version 2
                 (IKEv2).";
  }

  typedef auth-method-type {
    type enumeration {
      enum pre-shared {
        description
          "Select pre-shared key as the
           authentication method.";
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2).";
      }
      enum eap {
        description
          "Select the Extensible Authentication Protocol (EAP) as
           the authentication method.";
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2).";
      }
      enum digital-signature {
        description
          "Select digital signature as the authentication method.";
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2)
           RFC 7427: Signature Authentication in the Internet Key
                     Exchange Version 2 (IKEv2).";
      }
      enum null {
        description
          "Null authentication.";
        reference
          "RFC 7619: The NULL Authentication Method in the Internet
                     Key Exchange Protocol Version 2 (IKEv2).";
      }
    }
    description
      "Peer authentication method specified in the Peer
       Authorization Database (PAD).";
  }

  container ipsec-ike {
    description
      "IKE configuration for an NSF.  It includes PAD
       parameters, IKE connection information, and state
       data.";
    container pad {
      description
        "Configuration of the Peer Authorization Database
         (PAD).  Each entry of PAD contains authentication
         information of either the local peer or the remote peer.
         Therefore, the I2NSF Controller stores authentication
         information (and credentials) not only for the remote NSF
         but also for the local NSF.  The local NSF MAY use the
         same identity for different types of authentication
         and credentials.  Pointing to the entry for a local NSF
         (e.g., A) and the entry for remote NSF (e.g., B)
         is possible to specify all the required information to
         carry out the authentication between A and B (see
         ../conn-entry/local and ../conn-entry/remote).";
      list pad-entry {
        key "name";
        ordered-by user;
        description
          "Peer Authorization Database (PAD) entry.  It
           is a list of PAD entries ordered by the
           I2NSF Controller, and each entry is
           unequivocally identified by a name.";
        leaf name {
          type string;
          description
            "PAD-unique name to identify this
             entry.";
        }
        choice identity {
          mandatory true;
          description
            "A particular IKE peer will be
             identified by one of these identities.
             This peer can be a remote peer or local
             peer (this NSF).";
          reference
            "RFC 4301: Security Architecture for the Internet
                       Protocol, Section 4.4.3.1.";
          case ipv4-address {
            leaf ipv4-address {
              type inet:ipv4-address;
              description
                "Specifies the identity as
                 a single 4-octet IPv4 address.";
            }
          }
          case ipv6-address {
            leaf ipv6-address {
              type inet:ipv6-address;
              description
                "Specifies the identity as a
                 single 16-octet IPv6
                 address.  An example is
                 2001:db8::8:800:200c:417a.";
            }
          }
          case fqdn-string {
            leaf fqdn-string {
              type inet:domain-name;
              description
                "Specifies the identity as a
                 Fully Qualified Domain Name
                 (FQDN) string.  An example is
                 example.com.  The string MUST
                 NOT contain any terminators
                 (e.g., NULL, Carriage Return
                 (CR), etc.).";
            }
          }
          case rfc822-address-string {
            leaf rfc822-address-string {
              type string;
              description
                "Specifies the identity as a
                 fully qualified  email address
                 string (RFC 5322).  An example is
                 jsmith@example.com.  The string
                 MUST NOT contain any
                 terminators (e.g., NULL, CR,
                 etc.).";
              reference
                "RFC 5322: Internet Message Format.";
            }
          }
          case dnx509 {
            leaf dnx509 {
              type binary;
              description
                "The binary
                 Distinguished Encoding Rules (DER)
                 encoding of an ASN.1 X.500
                 Distinguished Name, as specified in IKEv2.";
              reference
                "RFC 5280: Internet X.509 Public Key Infrastructure
                           Certificate and Certificate Revocation
                           List (CRL) Profile
                 RFC 7296: Internet Key Exchange Protocol Version 2
                           (IKEv2), Section 3.5.";
            }
          }
          case gnx509 {
            leaf gnx509 {
              type binary;
              description
                "ASN.1 X.509 GeneralName structure,
                 as specified in RFC 5280, encoded
                 using ASN.1 Distinguished Encoding Rules
                 (DER), as specified in ITU-T X.690.";
              reference
                "RFC 5280: Internet X.509 Public Key Infrastructure
                           Certificate and Certificate Revocation
                           List (CRL) Profile.";
            }
          }
          case id-key {
            leaf id-key {
              type binary;
              description
                "Opaque octet stream that may be
                 used to pass vendor-specific
                 information for proprietary
                 types of identification.";
              reference
                "RFC 7296: Internet Key Exchange Protocol Version 2
                           (IKEv2), Section 3.5.";
            }
          }
          case id-null {
            leaf id-null {
              type empty;
              description
                "The ID_NULL identification is used
                 when the IKE identification payload
                 is not used.";
              reference
                "RFC 7619: The NULL Authentication Method in the
                           Internet Key Exchange Protocol Version 2
                           (IKEv2).";
            }
          }
        }
        leaf auth-protocol {
          type auth-protocol-type;
          default "ikev2";
          description
            "Only IKEv2 is supported right now, but
             other authentication protocols may be
             supported in the future.";
        }
        container peer-authentication {
          description
            "This container allows the security
             controller to configure the
             authentication method (pre-shared key,
             eap, digital-signature, null) that
             will be used with a particular peer and
             the credentials to use, which will
             depend on the selected authentication
             method.";
          leaf auth-method {
            type auth-method-type;
            default "pre-shared";
            description
              "Type of authentication method
               (pre-shared key, eap, digital signature,
               null).";
            reference
              "RFC 7296: Internet Key Exchange Protocol Version 2
                         (IKEv2), Section 2.15.";
          }
          container eap-method {
            when "../auth-method = 'eap'";
            leaf eap-type {
              type uint32 {
                range "1 .. 4294967295";
              }
              mandatory true;
              description
                "EAP method type specified with
                 a value extracted from the
                 IANA registry.  This
                 information provides the
                 particular EAP method to be
                 used.  Depending on the EAP
                 method, pre-shared keys or
                 certificates may be used.";
            }
            description
              "EAP method description used when
               authentication method is 'eap'.";
            reference
              "IANA: Extensible Authentication Protocol (EAP)
                     Registry, Method Types
               RFC 7296: Internet Key Exchange Protocol Version 2
                         (IKEv2), Section 2.16.";
          }
          container pre-shared {
            when "../auth-method[.='pre-shared' or
                  .='eap']";
            leaf secret {
              nacm:default-deny-all;
              type yang:hex-string;
              description
                "Pre-shared secret value.  The
                 NSF has to prevent read access
                 to this value for security
                 reasons.  This value MUST be
                 set if the EAP method uses a
                 pre-shared key or pre-shared
                 authentication has been chosen.";
            }
            description
              "Shared secret value for PSK or
               EAP method authentication based on
               PSK.";
          }
          container digital-signature {
            when "../auth-method[.='digital-signature'
                  or .='eap']";
            leaf ds-algorithm {
              type uint8;
              default "14";
              description
                "The digital signature
                 algorithm is specified with a
                 value extracted from the IANA
                 registry.  Default is the generic
                 digital signature method.  Depending
                 on the algorithm, the following leafs
                 MUST contain information.  For
                 example, if digital signature or the
                 EAP method involves a certificate,
                 then leaves 'cert-data' and 'private-key'
                 will contain this information.";
              reference
                "IANA: Internet Key Exchange Version 2 (IKEv2)
                       Parameters, IKEv2 Authentication Method.";
            }
            choice public-key {
              leaf raw-public-key {
                type binary;
                description
                  "A binary that contains the
                   value of the public key.  The
                   interpretation of the content
                   is defined by the 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 'publicKey'
                   described in RFC 5915.";
                reference
                  "RFC 5915: Elliptic Curve Private Key
                             Structure
                   RFC 8017: PKCS #1: RSA Cryptography
                             Specifications Version 2.2.";
              }
              leaf cert-data {
                type binary;
                description
                  "X.509 certificate data in DER
                   format.  If raw-public-key is
                   defined, this leaf is empty.";
                reference
                  "RFC 5280: Internet X.509 Public Key
                             Infrastructure Certificate
                             and Certificate Revocation
                             List (CRL) Profile.";
              }
              description
                "If the I2NSF Controller
                 knows that the NSF
                 already owns a private key
                 associated to this public key
                 (e.g., the NSF generated the pair
                 public key/private key out of
                 band), it will only configure
                 one of the leaves of this
                 choice but not the leaf
                 private-key.  The NSF, based on
                 the public key value, can know
                 the private key to be used.";
            }
            leaf private-key {
              nacm:default-deny-all;
              type binary;
              description
                "A binary that contains the
                 value of the private key.  The
                 interpretation of the content
                 is defined by the digital
                 signature algorithm.  For
                 example, an RSA key is
                 represented as RSAPrivateKey, as
                 defined in RFC 8017, and an
                 Elliptic Curve Cryptography
                 (ECC) key is represented as
                 ECPrivateKey, as defined in RFC
                 5915.  This value is set
                 if public key is defined and the
                 I2NSF Controller is in charge
                 of configuring the
                 private key.  Otherwise, it is
                 not set and the value is
                 kept in secret.";
              reference
                "RFC 5915: Elliptic Curve Private Key
                           Structure
                 RFC 8017: PKCS #1: RSA Cryptography
                           Specifications Version 2.2.";
            }
            leaf-list ca-data {
              type binary;
              description
                "List of trusted Certification
                 Authorities (CAs) certificates
                 encoded using ASN.1
                 Distinguished Encoding Rules
                 (DER).  If it is not defined,
                 the default value is empty.";
            }
            leaf crl-data {
              type binary;
              description
                "A CertificateList structure, as
                 specified in RFC 5280,
                 encoded using ASN.1
                 Distinguished Encoding Rules
                 (DER), as specified in ITU-T
                 X.690.  If it is not defined,
                 the default value is empty.";
              reference
                "RFC 5280: Internet X.509 Public Key Infrastructure
                           Certificate and Certificate Revocation
                           List (CRL) Profile.";
            }
            leaf crl-uri {
              type inet:uri;
              description
                "X.509 Certificate Revocation List
                 (CRL) certificate URI.
                 If it is not defined,
                 the default value is empty.";
              reference
                "RFC 5280: Internet X.509 Public Key Infrastructure
                           Certificate and Certificate Revocation
                           List (CRL) Profile.";
            }
            leaf oscp-uri {
              type inet:uri;
              description
                "Online Certificate Status Protocol
                 (OCSP) URI.  If it is not defined,
                 the default value is empty.";
              reference
                "RFC 6960: X.509 Internet Public Key Infrastructure
                           Online Certificate Status Protocol - OCSP
                 RFC 5280: Internet X.509 Public Key Infrastructure
                           Certificate and Certificate Revocation
                           List (CRL) Profile.";
            }
            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 peer
         with other peers.  This will create, in
         real time, IKE Security Associations
         established with these nodes.";
      leaf name {
        type string;
        description
          "Identifier for this connection
           entry.";
      }
      leaf autostartup {
        type autostartup-type;
        default "add";
        description
          "By default, only add configuration
           without starting the security
           association.";
      }
      leaf initial-contact {
        type boolean;
        default "false";
        description
          "The goal of this value is to deactivate the
           usage of INITIAL_CONTACT notification
           (true).  If this flag remains set to false, it
           means the usage of the INITIAL_CONTACT
           notification will depend on the IKEv2
           implementation.";
      }
      leaf version {
        type auth-protocol-type;
        default "ikev2";
        description
          "IKE version.  Only version 2 is supported.";
      }
      container fragmentation {
        leaf enabled {
          type boolean;
          default "false";
          description
            "Whether or not to enable IKEv2
             fragmentation (true or false).";
          reference
            "RFC 7383: Internet Key Exchange Protocol Version 2
                       (IKEv2) Message Fragmentation.";
        }
        leaf mtu {
          when "../enabled='true'";
          type uint16 {
            range "68..65535";
          }
          description
            "MTU that IKEv2 can use
             for IKEv2 fragmentation.";
          reference
            "RFC 7383: Internet Key Exchange Protocol Version 2
                       (IKEv2) Message Fragmentation.";
        }
        description
          "IKEv2 fragmentation, as per RFC 7383.  If the
           IKEv2 fragmentation is enabled, it is possible
           to specify the MTU.";
      }
      container ike-sa-lifetime-soft {
        description
          "IKE SA lifetime soft.  Two lifetime values
           can be configured: either rekey time of the
           IKE SA or reauth time of the IKE SA.  When
           the rekey lifetime expires, a rekey of the
           IKE SA starts.  When reauth lifetime
           expires, an IKE SA reauthentication starts.";
        leaf rekey-time {
          type uint32;
          units "seconds";
          default "0";
          description
            "Time in seconds between each IKE SA
             rekey.  The value 0 means infinite.";
        }
        leaf reauth-time {
          type uint32;
          units "seconds";
          default "0";
          description
            "Time in seconds between each IKE SA
             reauthentication.  The value 0 means
             infinite.";
        }
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2), Section 2.8.";
      }
      container ike-sa-lifetime-hard {
        description
          "Hard IKE SA lifetime.  When this
           time is reached, the IKE SA is removed.";
        leaf over-time {
          type uint32;
          units "seconds";
          default "0";
          description
            "Time in seconds before the IKE SA is
             removed.  The value 0 means infinite.";
        }
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2).";
      }
      leaf-list ike-sa-intr-alg {
        type nsfikec:intr-alg-t;
        default "12";
        ordered-by user;
        description
          "Integrity algorithm for establishing
           the IKE SA.  This list is ordered following
           from the higher priority to lower priority.
           The first node of the list will be the
           algorithm with higher priority.
           Default value 12 (AUTH_HMAC_SHA2_256_128).";
      }
      list ike-sa-encr-alg {
        key "id";
        min-elements 1;
        ordered-by user;
        leaf id {
          type uint16;
          description
            "An identifier that unequivocally
             identifies each entry of the list,
             i.e., an encryption algorithm and
             its key length (if required).";
        }
        leaf algorithm-type {
          type nsfikec:encr-alg-t;
          default "12";
          description
            "Default value 12 (ENCR_AES_CBC).";
        }
        leaf key-length {
          type uint16;
          default "128";
          description
            "By default, key length is 128 bits.";
        }
        description
          "Encryption or AEAD algorithm for the IKE
           SAs.  This list is ordered following
           from the higher priority to lower priority.
           The first node of the list will be the
           algorithm with higher priority.";
      }
      leaf dh-group {
        type fs-group;
        default "14";
        description
          "Group number for Diffie-Hellman
           Exponentiation used during IKE_SA_INIT
           for the IKE SA key exchange.";
      }
      leaf half-open-ike-sa-timer {
        type uint32;
        units "seconds";
        default "0";
        description
          "Set the half-open IKE SA timeout
           duration.  The value 0 implies infinite.";
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2), Section 2.";
      }
      leaf half-open-ike-sa-cookie-threshold {
        type uint32;
        default "0";
        description
          "Number of half-open IKE SAs that activate
           the cookie mechanism.  The value 0 implies
           infinite.";
        reference
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2), Section 2.6.";
      }
      container local {
        leaf local-pad-entry-name {
          type string;
          mandatory true;
          description
            "Local peer authentication information.
             This node points to a specific entry in
             the 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 remote-pad-entry-name {
          type string;
          mandatory true;
          description
            "Remote peer authentication information.
             This node points to a specific entry in
             the PAD where the authorization
             information about this particular
             remote peer is stored.  It MUST match a
             pad-entry-name.";
        }
        description
          "Remote peer authentication information.";
      }
      container encapsulation-type {
        uses nsfikec:encap;
        description
          "This container carries configuration
           information about the source and destination
           ports of encapsulation that IKE should use
           and the type of encapsulation that
           should be used when NAT traversal is required.
           However, this is just a best effort since
           the IKE implementation may need to use a
           different encapsulation, as described in
           RFC 8229.";
        reference
          "RFC 8229: TCP Encapsulation of IKE and IPsec
                     Packets.";
      }
      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 name {
            type string;
            description
              "SPD-entry-unique name to identify
               the IPsec policy.";
          }
          container ipsec-policy-config {
            description
              "This container carries the
               configuration of an IPsec policy.";
            uses nsfikec:ipsec-policy-grouping;
          }
          description
            "List of entries that will constitute
             the representation of the SPD.  In this
             case, since the NSF implements IKE, it
             is only required to send an IPsec 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
          "RFC 7296: Internet Key Exchange Protocol Version 2
                     (IKEv2), Section 2.9.";
      }
      container child-sa-info {
        leaf-list fs-groups {
          type fs-group;
          default "0";
          ordered-by user;
          description
            "If non-zero, forward secrecy is
             required when a new IPsec SA is being
             created, the (non-zero) value indicates
             the group number to use for the key
             exchange process used to achieve forward
             secrecy.
             This list is ordered following from the
             higher priority to lower priority.  The
             first node of the list will be the
             algorithm with higher priority.";
        }
        container child-sa-lifetime-soft {
          description
            "Soft IPsec SA lifetime.
             After the lifetime, the action is
             defined in this container
             in the leaf action.";
          uses nsfikec:lifetime;
          leaf action {
            type nsfikec: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
              "RFC 4301: Security Architecture for the Internet
                         Protocol, Section 4.5
               RFC 7296: Internet Key Exchange Protocol Version 2
                         (IKEv2), Section 2.8.";
          }
        }
        container child-sa-lifetime-hard {
          description
            "IPsec SA lifetime hard.  The action will
             be to terminate the IPsec SA.";
          uses nsfikec:lifetime;
          reference
            "RFC 7296: Internet Key Exchange Protocol Version 2
                       (IKEv2), Section 2.8.";
        }
        description
          "Specific information for IPsec SAs.
           It includes the Perfect Forward Secrecy (PFS)
           group and IPsec SAs rekey lifetimes.";
      }
      container state {
        config false;
        leaf initiator {
          type boolean;
          description
            "It is acting as an initiator for this
             connection.";
        }
        leaf initiator-ikesa-spi {
          type ike-spi;
          description
            "Initiator's IKE SA SPI.";
        }
        leaf responder-ikesa-spi {
          type ike-spi;
          description
            "Responder's IKE SA SPI.";
        }
        leaf nat-local {
          type boolean;
          description
            "True if local endpoint is behind a
             NAT.";
        }
        leaf nat-remote {
          type boolean;
          description
            "True if remote endpoint is behind
             a NAT.";
        }
        container encapsulation-type {
          uses nsfikec:encap;
          description
            "This container provides information
             about the source and destination
             ports of encapsulation that IKE is
             using and the type of encapsulation
             when NAT traversal is required.";
          reference
            "RFC 8229: TCP Encapsulation of IKE and IPsec Packets.";
        }
        leaf established {
          type uint64;
          units "seconds";
          description
            "Seconds since this IKE SA has been
             established.";
        }
        leaf current-rekey-time {
          type uint64;
          units "seconds";
          description
            "Seconds before IKE SA is rekeyed.";
        }
        leaf current-reauth-time {
          type uint64;
          units "seconds";
          description
            "Seconds before IKE SA is
             reauthenticated.";
        }
        description
          "IKE state data for a particular
           connection.";
      } /* ike-sa-state */
    } /* ike-conn-entries */
    container number-ike-sas {
      config false;
      leaf total {
        type yang:gauge64;
        description
          "Total number of active IKE SAs.";
      }
      leaf half-open {
        type yang:gauge64;
        description
          "Number of half-open active IKE SAs.";
      }
      leaf half-open-cookies {
        type yang:gauge64;
        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 */
}

&lt;CODE ENDS&gt;</pre><a href="#section-5.2.3-2" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="ike-less-model">
<section id="section-5.3">
        <h3 id="name-the-ietf-i2nsf-ikeless-modu">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-the-ietf-i2nsf-ikeless-modu" class="section-name selfRef">The 'ietf-i2nsf-ikeless' Module</a>
        </h3>
<p id="section-5.3-1">In this section, the YANG module for the IKE-less case is described.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<div id="ikeless-overview">
<section id="section-5.3.1">
          <h4 id="name-data-model-overview-3">
<a href="#section-5.3.1" class="section-number selfRef">5.3.1. </a><a href="#name-data-model-overview-3" class="section-name selfRef">Data Model Overview</a>
          </h4>
<p id="section-5.3.1-1"> For this case, the definition of the SPD model has been
                        mainly extracted from the specification in Section
                        <a href="https://www.rfc-editor.org/rfc/rfc4301#section-4.4.1" class="relref">4.4.1</a> and Appendix <a href="https://www.rfc-editor.org/rfc/rfc4301#appendix-D" class="relref">D</a> in <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>,
                        though with some changes, namely:<a href="#section-5.3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3.1-2.1">For simplicity, each IPsec policy (spd-entry) contains one
                            Traffic Selector, instead of a list of them. The
                            reason is that actual kernel
                            implementations only admit a single Traffic
                            Selector per IPsec policy.<a href="#section-5.3.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.2">Each IPsec policy contains an identifier (reqid)
                            to relate the policy with the IPsec SA. This is
                            common in Linux-based systems.<a href="#section-5.3.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.3">Each IPsec policy has only one name and not a
                            list of names.<a href="#section-5.3.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.4">Combined algorithms have been removed because
                            encryption algorithms <span class="bcp14">MAY</span> include Authenticated
                            Encryption with Associated Data (AEAD).<a href="#section-5.3.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-2.5">Tunnel information has been extended
                            with information about DSCP mapping. 
                            The reason is that certain kernel
                            implementations accept configuration of
                            these values.<a href="#section-5.3.1-2.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.3.1-3">The definition of the SAD model has been mainly
             extracted from the specification in
             <span><a href="https://www.rfc-editor.org/rfc/rfc4301#section-4.4.2" class="relref">Section 4.4.2</a> of [<a href="#RFC4301" class="xref">RFC4301</a>]</span>, 
             though with some changes, namely:<a href="#section-5.3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.3.1-4.1">For simplicity, each IPsec SA
                            (sad-entry) contains one Traffic
                            Selector, instead of a list of them. The
                            reason is that actual kernel
                            implementations
                            only admit a single Traffic Selector per
                            IPsec SA.<a href="#section-5.3.1-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.2">Each IPsec SA contains an identifier (reqid) to
                            relate the IPsec SA with the IPsec policy. The reason
                            is that real kernel implementations allow
              this value to be included.<a href="#section-5.3.1-4.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.3">Each IPsec SA is also named in the same way as
                            IPsec policies.<a href="#section-5.3.1-4.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.4">The model allows specifying the
                            algorithm for encryption. This can be
                            Authenticated Encryption with Associated
                            Data (AEAD) or non-AEAD. If an AEAD algorithm is
                            specified, the integrity algorithm is not
                            required. If a non-AEAD algorithm is
                            specified, the integrity algorithm is
                            required <span>[<a href="#RFC8221" class="xref">RFC8221</a>]</span>.<a href="#section-5.3.1-4.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.5">Tunnel information has been extended
                            with information about Differentiated
                            Services Code Point (DSCP) mapping. It
                            is assumed that
                            NSFs involved in this document provide
                            ECN full functionality to prevent
                            discarding of ECN congestion
                            indications <span>[<a href="#RFC6040" class="xref">RFC6040</a>]</span>.<a href="#section-5.3.1-4.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.6">The lifetime of the IPsec SAs also
                            includes idle time
                            and the number of IP packets as a threshold to trigger
                            the lifetime. The reason is that 
                            actual kernel implementations allow for setting these
                            types of lifetimes.<a href="#section-5.3.1-4.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.3.1-4.7">Information to configure the type of  
                            encapsulation (encapsulation-type) for IPsec ESP
                            packets in UDP <span>[<a href="#RFC3948" class="xref">RFC3948</a>]</span>
                            or TCP <span>[<a href="#RFC8229" class="xref">RFC8229</a>]</span> has been included.<a href="#section-5.3.1-4.7" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.3.1-5"> The notifications model has been defined using, as
                        reference, the PF_KEYv2 specification in 
                        <span>[<a href="#RFC2367" class="xref">RFC2367</a>]</span>.<a href="#section-5.3.1-5" class="pilcrow">¶</a></p>
<p id="section-5.3.1-6"> The YANG data model for the IKE-less case is defined by the module "ietf-i2nsf-ikeless". Its structure is depicted in the following diagram, using the notation syntax for YANG tree diagrams <span>[<a href="#RFC8340" class="xref">RFC8340</a>]</span>.<a href="#section-5.3.1-6" class="pilcrow">¶</a></p>
<div id="section-5.3.1-7">
<pre class="sourcecode lang-yangtree">
module: ietf-i2nsf-ikeless
  +--rw ipsec-ikeless
    +--rw spd
    |  +--rw spd-entry* [name]
    |     +--rw name  string
    |     +--rw direction nsfikec:ipsec-traffic-direction
    |     +--rw reqid? uint64
    |     +--rw ipsec-policy-config
    |        +--rw anti-replay-window-size?   uint32
    |        +--rw traffic-selector
    |        |  +--rw local-prefix      inet:ip-prefix
    |        |  +--rw remote-prefix     inet:ip-prefix
    |        |  +--rw inner-protocol?   ipsec-inner-protocol
    |        |  +--rw local-ports* [start end]
    |        |  |  +--rw start    inet:port-number
    |        |  |  +--rw end      inet:port-number
    |        |  +--rw remote-ports* [start end]
    |        |     +--rw start    inet:port-number
    |        |     +--rw end      inet:port-number
    |        +--rw processing-info
    |           +--rw action?         ipsec-spd-action
    |           +--rw ipsec-sa-cfg
    |             +--rw pfp-flag?              boolean
    |             +--rw ext-seq-num?           boolean
    |             +--rw seq-overflow?          boolean
    |             +--rw stateful-frag-check?   boolean
    |             +--rw mode?                  ipsec-mode
    |             +--rw protocol-parameters? ipsec-protocol-params
    |              +--rw esp-algorithms
    |              |  +--rw integrity*    intr-alg-t
    |              |  +--rw encryption* [id]
    |              |  |  +--rw id                uint16
    |              |  |  +--rw algorithm-type?   encr-alg-t
    |              |  |  +--rw key-length?       uint16
    |              |  +--rw tfc-pad?      boolean
    |              +--rw tunnel
    |                 +--rw local           inet:ip-address
    |                 +--rw remote          inet:ip-address
    |                 +--rw df-bit?         enumeration
    |                 +--rw bypass-dscp?    boolean
    |                 +--rw dscp-mapping* [id]
    |                    +--rw id            uint8
    |                    +--rw inner-dscp?   inet:dscp
    |                    +--rw outer-dscp?   inet:dscp
    +--rw sad
      +--rw sad-entry* [name]
       +--rw name               string
       +--rw reqid?             uint64
       +--rw ipsec-sa-config
       |  +--rw spi                        uint32
       |  +--rw ext-seq-num?               boolean
       |  +--rw seq-overflow?              boolean
       |  +--rw anti-replay-window-size?   uint32
       |  +--rw traffic-selector
       |  |  +--rw local-prefix      inet:ip-prefix
       |  |  +--rw remote-prefix     inet:ip-prefix
       |  |  +--rw inner-protocol?   ipsec-inner-protocol
       |  |  +--rw local-ports* [start end]
       |  |  |  +--rw start    inet:port-number
       |  |  |  +--rw end      inet:port-number
       |  |  +--rw remote-ports* [start end]
       |  |     +--rw start    inet:port-number
       |  |     +--rw end      inet:port-number
       |  +--rw protocol-parameters? nsfikec:ipsec-protocol-params
       |  +--rw mode?                      nsfikec:ipsec-mode
       |  +--rw esp-sa
       |  |  +--rw encryption
       |  |  |  +--rw encryption-algorithm?   nsfikec:encr-alg-t
       |  |  |  +--rw key?                    yang:hex-string
       |  |  |  +--rw iv?                     yang:hex-string
       |  |  +--rw integrity
       |  |     +--rw integrity-algorithm?   nsfikec:intr-alg-t
       |  |     +--rw key?                   yang:hex-string
       |  +--rw sa-lifetime-hard
       |  |  +--rw time?      uint32
       |  |  +--rw bytes?     yang:counter64
       |  |  +--rw packets?   uint32
       |  |  +--rw idle?      uint32
       |  +--rw sa-lifetime-soft
       |  |  +--rw time?      uint32
       |  |  +--rw bytes?     yang:counter64
       |  |  +--rw packets?   uint32
       |  |  +--rw idle?      uint32
       |  |  +--rw action?    nsfikec:lifetime-action
       |  +--rw tunnel
       |  |  +--rw local           inet:ip-address
       |  |  +--rw remote          inet:ip-address
       |  |  +--rw df-bit?         enumeration
       |  |  +--rw bypass-dscp?    boolean
       |  |  +--rw dscp-mapping* [id]
       |  |  |  +--rw id            uint8
       |  |  |  +--rw inner-dscp?   inet:dscp
       |  |  |  +--rw outer-dscp?   inet:dscp
       |  |  +--rw dscp-values*    inet:dscp
       |  +--rw encapsulation-type
       |     +--rw espencap?   esp-encap
       |     +--rw sport?      inet:port-number
       |     +--rw dport?      inet:port-number
       |     +--rw oaddr*      inet:ip-address
       +--ro ipsec-sa-state
          +--ro sa-lifetime-current
          |  +--ro time?      uint32
          |  +--ro bytes?     yang:counter64
          |  +--ro packets?   uint32
          |  +--ro idle?      uint32
          +--ro replay-stats
             +--ro replay-window
             |  +--ro w?   uint32
             |  +--ro t?   uint64
             |  +--ro b?   uint64
             +--ro packet-dropped?       yang:counter64
             +--ro failed?               yang:counter64
             +--ro seq-number-counter?   uint64

   notifications:
     +---n sadb-acquire {ikeless-notification}?
     |  +--ro ipsec-policy-name    string
     |  +--ro traffic-selector
     |     +--ro local-prefix      inet:ip-prefix
     |     +--ro remote-prefix     inet:ip-prefix
     |     +--ro inner-protocol?   ipsec-inner-protocol
     |     +--ro local-ports* [start end]
     |     |  +--ro start    inet:port-number
     |     |  +--ro end      inet:port-number
     |     +--ro remote-ports* [start end]
     |        +--ro start    inet:port-number
     |        +--ro end      inet:port-number
     +---n sadb-expire {ikeless-notification}?
     |  +--ro ipsec-sa-name           string
     |  +--ro soft-lifetime-expire?   boolean
     |  +--ro lifetime-current
     |     +--ro time?      uint32
     |     +--ro bytes?     yang:counter64
     |     +--ro packets?   uint32
     |     +--ro idle?      uint32
     +---n sadb-seq-overflow {ikeless-notification}?
     |  +--ro ipsec-sa-name    string
     +---n sadb-bad-spi {ikeless-notification}?
        +--ro spi    uint32
</pre><a href="#section-5.3.1-7" class="pilcrow">¶</a>
</div>
<p id="section-5.3.1-8"> The YANG data model consists of a unique
                    "ipsec-ikeless" container, which, in turn, is
                    composed of two additional containers: "spd" and
                    "sad". The "spd" container consists of a list of
                    entries that form the Security Policy Database.
                    Compared to the IKE case YANG data model, this
                    part specifies a few additional parameters
                    necessary due to the absence of an IKE software
                    in the NSF: traffic direction to apply the IPsec
                    policy and a "reqid" value to link an IPsec
                    policy with its associated IPsec SAs since it is
                    otherwise a little hard to find by searching. 
                    The "sad" container is a list of entries that form the Security Association Database. In general, each entry allows specifying both configuration information (SPI, Traffic Selectors, tunnel/transport mode, cryptographic algorithms and keying material, soft/hard lifetimes, etc.) as well as stating information (time to expire, replay statistics, etc.) of a concrete IPsec SA.<a href="#section-5.3.1-8" class="pilcrow">¶</a></p>
<p id="section-5.3.1-9">In addition, the module defines a set of notifications to allow 
   the NSF to inform the I2NSF Controller about relevant events, such 
   as IPsec SA expiration, sequence number overflow, or bad SPI in a received packet.<a href="#section-5.3.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ikeless-examples">
<section id="section-5.3.2">
          <h4 id="name-example-usage-2">
<a href="#section-5.3.2" class="section-number selfRef">5.3.2. </a><a href="#name-example-usage-2" class="section-name selfRef">Example Usage</a>
          </h4>
<p id="section-5.3.2-1">
                        <a href="#appendix-e" class="xref">Appendix B</a> shows an example
                        of an IKE-less case configuration for an NSF in
                        transport mode (host-to-host). Additionally,
                        <a href="#appendix-f" class="xref">Appendix C</a> shows examples
                        of IPsec SA expire, acquire, sequence number
                        overflow, and bad SPI notifications.<a href="#section-5.3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ikeless-module">
<section id="section-5.3.3">
          <h4 id="name-yang-module-3">
<a href="#section-5.3.3" class="section-number selfRef">5.3.3. </a><a href="#name-yang-module-3" class="section-name selfRef">YANG Module</a>
          </h4>
<p id="section-5.3.3-1">
                      This YANG module has normative references to
                      <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>, 
       <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span>,
                      <span>[<a href="#RFC6991" class="xref">RFC6991</a>]</span>, 
                      <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> and 
                      <span>[<a href="#RFC8341" class="xref">RFC8341</a>]</span>.<a href="#section-5.3.3-1" class="pilcrow">¶</a></p>
<div id="section-5.3.3-2">
<pre class="sourcecode lang-yang">&lt;CODE BEGINS&gt; file "ietf-i2nsf-ikeless@2021-07-14.yang"


module ietf-i2nsf-ikeless {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
  prefix nsfikels;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types.";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types.";
  }
  import ietf-i2nsf-ikec {
    prefix nsfikec;
    reference
      "RFC 9061: A YANG Data Model for IPsec Flow Protection
                 Based on Software-Defined Networking (SDN).";
  }
  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control
                 Model.";
  }

  organization
    "IETF I2NSF Working Group";
  contact
    "WG Web:  &lt;https://datatracker.ietf.org/wg/i2nsf/&gt;
     WG List: &lt;mailto:i2nsf@ietf.org&gt;

     Author: Rafael Marin-Lopez
              &lt;mailto:rafa@um.es&gt;

     Author: Gabriel Lopez-Millan
              &lt;mailto:gabilm@um.es&gt;

     Author: Fernando Pereniguez-Garcia
              &lt;mailto:fernando.pereniguez@cud.upct.es&gt;
    ";
  description
    "Data model for IKE-less case in the SDN-based IPsec flow
     protection service.

     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.

     Copyright (c) 2021 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 9061; see
     the RFC itself for full legal notices.";

  revision 2021-07-14 {
    description
      "Initial version.";
    reference
      "RFC 9061: A YANG Data Model for IPsec Flow Protection
                 Based on Software-Defined Networking (SDN).";
  }

  feature ikeless-notification {
    description
      "This feature indicates that the server supports
       generating notifications in the ikeless module.

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

  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
       I2NSF Controller to configure IPsec policies in
       the Security Policy Database (SPD), and the second
       allows the I2NSF Controller to configure IPsec
       Security Associations (IPsec SAs) in the Security
       Association Database (SAD).";
    reference
      "RFC 4301: Security Architecture for the Internet Protocol.";
    container spd {
      description
        "Configuration of the Security Policy Database
         (SPD).";
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.1.2.";
      list spd-entry {
        key "name";
        ordered-by user;
        leaf name {
          type string;
          description
            "SPD-entry-unique name to identify this
             entry.";
        }
        leaf direction {
          type nsfikec:ipsec-traffic-direction;
          mandatory true;
          description
            "Inbound traffic or outbound
             traffic.  In the IKE-less case, the
             I2NSF Controller needs to
             specify the policy direction to be
             applied in the NSF.  In the IKE case,
             this direction does not need to be
             specified, since IKE
             will determine the direction that the
             IPsec policy will require.";
        }
        leaf reqid {
          type uint64;
          default "0";
          description
            "This value allows linking this
             IPsec policy with IPsec SAs with the
             same reqid.  It is only required in
             the IKE-less model since, in the IKE
             case, this link is handled internally
             by IKE.";
        }
        container ipsec-policy-config {
          description
            "This container carries the
             configuration of an IPsec policy.";
          uses nsfikec:ipsec-policy-grouping;
        }
        description
          "The SPD is represented as a list of SPD
           entries, where each SPD entry represents an
           IPsec policy.";
      } /*list spd-entry*/
    } /*container spd*/
    container sad {
      description
        "Configuration of the IPsec Security Association
         Database (SAD).";
      reference
        "RFC 4301: Security Architecture for the Internet Protocol,
                   Section 4.4.2.1.";
      list sad-entry {
        key "name";
        ordered-by user;
        leaf name {
          type string;
          description
            "SAD-entry-unique name to identify this
             entry.";
        }
        leaf reqid {
          type uint64;
          default "0";
          description
            "This value allows linking this
             IPsec SA with an IPsec policy with
             the same reqid.";
        }
        container ipsec-sa-config {
          description
            "This container allows configuring
             details of an IPsec SA.";
          leaf spi {
            type uint32 {
              range "0..max";
            }
            mandatory true;
            description
              "IPsec SA of Security Parameter Index (SPI).";
          }
          leaf ext-seq-num {
            type boolean;
            default "true";
            description
              "True if this IPsec SA is using extended
               sequence numbers.  If true, the 64-bit
               extended sequence number counter is used;
               if false, the normal 32-bit sequence
               number counter is used.";
          }
          leaf seq-overflow {
            type boolean;
            default "false";
            description
              "The flag indicating whether
               overflow of the sequence number
               counter should prevent transmission
               of 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 (leaf
               esp-algorithms/encryption/algorithm-type),
               this flag MUST BE false. Setting this
               flag to true is strongly discouraged.";
          }
          leaf anti-replay-window-size {
            type uint32;
            default "64";
            description
              "To set the anti-replay window size.
               The default value is set to 64,
               following the recommendation in RFC 4303.";
            reference
              "RFC 4303: IP Encapsulating Security Payload (ESP),
                         Section 3.4.3.";
          }
          container traffic-selector {
            uses nsfikec:selector-grouping;
            description
              "The IPsec SA Traffic Selector.";
          }
          leaf protocol-parameters {
            type nsfikec:ipsec-protocol-params;
            default "esp";
            description
              "Security protocol of IPsec SA, only
               ESP so far.";
          }
          leaf mode {
            type nsfikec:ipsec-mode;
            default "transport";
            description
              "Tunnel or transport mode.";
          }
          container esp-sa {
            when "../protocol-parameters = 'esp'";
            description
              "In case the IPsec SA is an
               Encapsulation Security Payload
               (ESP), it is required to specify
               encryption and integrity
               algorithms and key materials.";
            container encryption {
              description
                "Configuration of encryption or
                 AEAD algorithm for IPsec
                 Encapsulation Security Payload
                 (ESP).";
              leaf encryption-algorithm {
                type nsfikec:encr-alg-t;
                default "12";
                description
                  "Configuration of ESP
                   encryption.  With AEAD
                   algorithms, the integrity-algorithm
                   leaf is not used.";
              }
              leaf key {
                nacm:default-deny-all;
                type yang:hex-string;
                description
                  "ESP encryption key value.
                   If this leaf is not defined,
                   the key is not defined
                   (e.g., encryption is NULL).
                   The key length is
                   determined by the
                   length of the key set in
                   this leaf.  By default, it is
                   128 bits.";
              }
              leaf iv {
                nacm:default-deny-all;
                type yang:hex-string;
                description
                  "ESP encryption IV value.  If
                   this leaf is not defined, the
                   IV is not defined (e.g.,
                   encryption is NULL).";
              }
            }
            container integrity {
              description
                "Configuration of integrity for
                 IPsec Encapsulation Security
                 Payload (ESP).  This container
                 allows configuration of integrity
                 algorithms when no AEAD
                 algorithms are used and
                 integrity is required.";
              leaf integrity-algorithm {
                type nsfikec:intr-alg-t;
                default "12";
                description
                  "Message Authentication Code
                   (MAC) algorithm to provide
                   integrity in ESP (default
                   AUTH_HMAC_SHA2_256_128).
                   With AEAD algorithms,
                   the integrity leaf is not
                   used.";
              }
              leaf key {
                nacm:default-deny-all;
                type yang:hex-string;
                description
                  "ESP integrity key value.
                   If this leaf is not defined,
                   the key is not defined (e.g.,
                   AEAD algorithm is chosen and
                   integrity algorithm is not
                   required).  The key length is
                   determined by the length of
                   the key configured.";
              }
            }
          } /*container esp-sa*/
          container sa-lifetime-hard {
            description
              "IPsec SA hard lifetime.  The action
               associated is terminate and hold.";
            uses nsfikec:lifetime;
          }
          container sa-lifetime-soft {
            description
              "IPsec SA soft lifetime.";
            uses nsfikec:lifetime;
            leaf action {
              type nsfikec:lifetime-action;
              description
                "Action lifetime: terminate-clear,
                 terminate-hold, or replace.";
            }
          }
          container tunnel {
            when "../mode = 'tunnel'";
            uses nsfikec:tunnel-grouping;
            leaf-list dscp-values {
              type inet:dscp;
              description
                "DSCP values allowed for ingress packets carried
                 over this IPsec SA.  If no values are specified, no
                 DSCP-specific filtering is applied.  When
                 ../bypass-dscp is false and a dscp-mapping is
                 defined, each value here would be the same as the
                 'inner' DSCP value for the DSCP mapping (list
                 dscp-mapping).";
              reference
                "RFC 4301: Security Architecture for the Internet
                           Protocol, Section 4.4.2.1.";
            }
            description
              "Endpoints of the IPsec tunnel.";
          }
          container encapsulation-type {
            uses nsfikec:encap;
            description
              "This container carries
               configuration information about
               the source and destination ports
               that will be used for ESP
               encapsulation of ESP packets and
               the type of encapsulation when NAT
               traversal is in place.";
          }
        } /*ipsec-sa-config*/
        container ipsec-sa-state {
          config false;
          description
            "Container describing IPsec SA state
             data.";
          container sa-lifetime-current {
            uses nsfikec:lifetime;
            description
              "SAD lifetime current.";
          }
          container replay-stats {
            description
              "State data about the anti-replay
               window.";
            container replay-window {
              leaf w {
                type uint32;
                description
                  "Size of the replay window.";
              }
              leaf t {
                type uint64;
                description
                  "Highest sequence number
                   authenticated so far,
                   upper bound of window.";
              }
              leaf b {
                type uint64;
                description
                  "Lower bound of window.";
              }
              description
                "This container contains three
                 parameters that define the state
                 of the replay window: window size (w),
                 highest sequence number authenticated (t),
                 and lower bound of the window (b), according
                 to Appendix A2.1 in RFC 4303 (w = t - b + 1).";
              reference
                "RFC 4303: IP Encapsulating Security Payload (ESP),
                           Appendix A.";
            }
            leaf packet-dropped {
              type yang:counter64;
              description
                "Packets dropped
                 because they are
                 replay packets.";
            }
            leaf failed {
              type yang:counter64;
              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 that form the SAD.";
      } /*list sad-entry*/
    } /*container sad*/
  } /*container ipsec-ikeless*/

  /* Notifications */

  notification sadb-acquire {
    if-feature "ikeless-notification";
    description
      "The NSF detects and notifies that
       an IPsec SA is required for an
       outbound IP packet that has matched an SPD entry.
       The traffic-selector container in this
       notification contains information about
       the IP packet that triggered this
       notification.";
    leaf ipsec-policy-name {
      type string;
      mandatory true;
      description
        "It contains the SPD entry name (unique) of
         the IPsec policy that hits the IP-packet-required
         IPsec SA.  It is assumed the
         I2NSF 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 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 nsfikec:selector-grouping;
    }
  }

  notification sadb-expire {
    if-feature "ikeless-notification";
    description
      "An IPsec SA expiration (soft or hard).";
    leaf ipsec-sa-name {
      type string;
      mandatory true;
      description
        "It contains the SAD entry name (unique) of
         the IPsec SA that is about to expire.  It is assumed
         the I2NSF 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 in order to
         perform a rekey (soft lifetime) or delete it
         (hard lifetime) with this unique identifier.";
    }
    leaf soft-lifetime-expire {
      type boolean;
      default "true";
      description
        "If this value is true, the lifetime expired is
         soft.  If it is false, the lifetime is hard.";
    }
    container lifetime-current {
      description
        "IPsec SA current lifetime.  If
         soft-lifetime-expired is true,
         this container is set with the
         lifetime information about current
         soft lifetime.
         It can help the NSF Controller
         to know which of the (soft) lifetime
         limits raised the event: time, bytes,
         packets, or idle.";
      uses nsfikec:lifetime;
    }
  }

  notification sadb-seq-overflow {
    if-feature "ikeless-notification";
    description
      "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 a sequence
         number overflow, and rollover is not permitted.
         When the NSF issues this event before reaching
         a sequence number, overflow is implementation
         specific and out of scope of this specification.
         It is assumed the I2NSF 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 in
         order to perform a rekey of the IPsec SA.";
    }
  }

  notification sadb-bad-spi {
    if-feature "ikeless-notification";
    description
      "Notify when the NSF receives a packet with an
       incorrect SPI (i.e., not present in the SAD).";
    leaf spi {
      type uint32 {
        range "0..max";
      }
      mandatory true;
      description
        "SPI number contained in the erroneous IPsec
         packet.";
    }
  }
}

&lt;CODE ENDS&gt;</pre><a href="#section-5.3.3-2" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="iana">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">IANA has registered the following namespaces in the "ns"
                   subregistry within the "IETF XML Registry" 
                   <span>[<a href="#RFC3688" class="xref">RFC3688</a>]</span>:<a href="#section-6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-2">
        <dt id="section-6-2.1">URI:</dt>
        <dd style="margin-left: 1.5em" id="section-6-2.2">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec<a href="#section-6-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-2.3">Registrant Contact:</dt>
        <dd style="margin-left: 1.5em" id="section-6-2.4">The IESG.<a href="#section-6-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-2.5">XML:</dt>
        <dd style="margin-left: 1.5em" id="section-6-2.6">N/A, the requested URI is an XML namespace.<a href="#section-6-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-3">
        <dt id="section-6-3.1">URI:</dt>
        <dd style="margin-left: 1.5em" id="section-6-3.2">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike<a href="#section-6-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-3.3">Registrant Contact:</dt>
        <dd style="margin-left: 1.5em" id="section-6-3.4">The IESG.<a href="#section-6-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-3.5">XML:</dt>
        <dd style="margin-left: 1.5em" id="section-6-3.6">N/A, the requested URI is an XML namespace.<a href="#section-6-3.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-4">
        <dt id="section-6-4.1">URI:</dt>
        <dd style="margin-left: 1.5em" id="section-6-4.2">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless<a href="#section-6-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-4.3">Registrant Contact:</dt>
        <dd style="margin-left: 1.5em" id="section-6-4.4">The IESG.<a href="#section-6-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-4.5">XML:</dt>
        <dd style="margin-left: 1.5em" id="section-6-4.6">N/A, the requested URI is an XML namespace.<a href="#section-6-4.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-6-5">IANA has registered the following YANG modules in the "YANG
                    Module Names" registry <span>[<a href="#RFC6020" class="xref">RFC6020</a>]</span>:<a href="#section-6-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-6">
        <dt id="section-6-6.1">Name:</dt>
        <dd style="margin-left: 7.0em" id="section-6-6.2">ietf-i2nsf-ikec<a href="#section-6-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-6.3">Maintained by IANA:</dt>
        <dd style="margin-left: 7.0em" id="section-6-6.4">N<a href="#section-6-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-6.5">Namespace:</dt>
        <dd style="margin-left: 7.0em" id="section-6-6.6">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec<a href="#section-6-6.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-6.7">Prefix:</dt>
        <dd style="margin-left: 7.0em" id="section-6-6.8">nsfikec<a href="#section-6-6.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-6.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-6-6.10">RFC 9061<a href="#section-6-6.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-7">
        <dt id="section-6-7.1">Name:</dt>
        <dd style="margin-left: 7.0em" id="section-6-7.2">ietf-i2nsf-ike<a href="#section-6-7.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-7.3">Maintained by IANA:</dt>
        <dd style="margin-left: 7.0em" id="section-6-7.4">N<a href="#section-6-7.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-7.5">Namespace:</dt>
        <dd style="margin-left: 7.0em" id="section-6-7.6">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike<a href="#section-6-7.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-7.7">Prefix:</dt>
        <dd style="margin-left: 7.0em" id="section-6-7.8">nsfike<a href="#section-6-7.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-7.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-6-7.10">RFC 9061<a href="#section-6-7.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-6-8">
        <dt id="section-6-8.1">Name:</dt>
        <dd style="margin-left: 7.0em" id="section-6-8.2">ietf-i2nsf-ikeless<a href="#section-6-8.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-8.3">Maintained by IANA:</dt>
        <dd style="margin-left: 7.0em" id="section-6-8.4">N<a href="#section-6-8.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-8.5">Namespace:</dt>
        <dd style="margin-left: 7.0em" id="section-6-8.6">urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless<a href="#section-6-8.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-8.7">Prefix:</dt>
        <dd style="margin-left: 7.0em" id="section-6-8.8">nsfikels<a href="#section-6-8.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-6-8.9">Reference:</dt>
        <dd style="margin-left: 7.0em" id="section-6-8.10">RFC 9061<a href="#section-6-8.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">
                    First of all, this document shares all the security
                    issues of SDN that are specified in the Security
                    Considerations sections of <span>[<a href="#ITU-T.Y.3300" class="xref">ITU-T.Y.3300</a>]</span>
                    and <span>[<a href="#RFC7426" class="xref">RFC7426</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">On the one hand, it is important to note that
                   there <span class="bcp14">MUST</span>
                    exist a security association between the I2NSF
                    Controller and the NSFs to protect the critical
                    information (cryptographic keys, configuration
                    parameter, etc.) exchanged between these
                    entities. The nature of and means to create that
                    security association is out of the scope of this
                    document (i.e., it is part of device
                    provisioning or onboarding).<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">On the other hand, if encryption is mandatory for all
                    traffic of an NSF, its default policy <span class="bcp14">MUST</span> be to drop
                    (DISCARD) packets to prevent cleartext packet leaks.
                    This default policy <span class="bcp14">MUST</span> be preconfigured in the startup 
                    configuration datastore in the NSF 
                    before the NSF contacts the
                    I2NSF Controller. Moreover, the startup configuration
                    datastore <span class="bcp14">MUST</span> be also preconfigured with the required
                    ALLOW policies that allow the NSF to communicate with the
                    I2NSF Controller once the NSF is deployed. This
                    preconfiguration step is not carried out by the
                    I2NSF Controller but by some other entity before the
                    NSF deployment. In this manner, when the NSF
                    starts/reboots, it will always first apply the
                    configuration in the startup configuration before
                    contacting the I2NSF Controller.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">Finally, this section is divided 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
                    I2NSF Controller, as typically in the SDN
                    paradigm, is a target for different type of
                    attacks; see 
                    <span>[<a href="#SDNSecServ" class="xref">SDNSecServ</a>]</span> and 
                    <span>[<a href="#SDNSecurity" class="xref">SDNSecurity</a>]</span>. Thus, the
                    I2NSF Controller is a key entity in the
                    infrastructure and <span class="bcp14">MUST</span> be protected accordingly. 
                    In particular, the I2NSF Controller will handle
                    cryptographic material; thus, the attacker may try to access
                    this information. The impact is different depending on the IKE
                    case or the IKE-less case.<a href="#section-7-4" class="pilcrow">¶</a></p>
<div id="sec-case1">
<section id="section-7.1">
        <h3 id="name-ike-case">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-ike-case" class="section-name selfRef">IKE Case</a>
        </h3>
<p id="section-7.1-1">In the IKE case, the I2NSF Controller sends IKEv2
                       credentials (PSK, public/private keys, certificates,
                       etc.) to the NSFs using the security association
                       between the I2NSF Controller and NSFs. The I2NSF 
                       Controller <span class="bcp14">MUST NOT</span> store the IKEv2 credentials after 
                       distributing them. Moreover, the NSFs <span class="bcp14">MUST NOT</span> allow 
                       the reading of these values once they have been applied 
                       by the I2NSF Controller (i.e., write-only operations). 
                       One option is to always return the same value (i.e., all
                       0s) if a read operation is carried out.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">If the attacker has access to the I2NSF Controller
                        during the period of time that key material is
                        generated, it might have access to the key material.
                        Since these values are used during NSF authentication in
                        IKEv2, it may impersonate the affected NSFs. Several
                        recommendations are important.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-3.1"> IKEv2 configurations <span class="bcp14">SHOULD</span> adhere to the 
                        recommendations in <span>[<a href="#RFC8247" class="xref">RFC8247</a>]</span>.<a href="#section-7.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-3.2"> If PSK authentication is
                        used in IKEv2, the I2NSF Controller <span class="bcp14">MUST</span> remove the
                        PSK immediately after generating and distributing it.<a href="#section-7.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-3.3">When public/private keys are used, the I2NSF
                        Controller <span class="bcp14">MAY</span> generate both public key and private
                        key. In such a case, the I2NSF Controller <span class="bcp14">MUST</span> remove
                        the associated private key immediately after
                        distributing them to the NSFs.
                        Alternatively, the NSF
                        <span class="bcp14">MAY</span> generate the private key and export only
                        the public key to the I2NSF Controller. How
                        the NSF generates these
                        cryptographic materials (public key/ private
                        keys) and
                        exports the public key is out of scope of
                        this document.<a href="#section-7.1-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-3.4">If certificates are used, the NSF <span class="bcp14">MAY</span> generate the
                        private key and export the public key for certification
                        to the I2NSF Controller. How the NSF generates these
                        cryptographic material (public key/ private keys) and
                        exports the public key is out of scope of this
                        document.<a href="#section-7.1-3.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sec-case2">
<section id="section-7.2">
        <h3 id="name-ike-less-case">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-ike-less-case" class="section-name selfRef">IKE-less Case</a>
        </h3>
<p id="section-7.2-1">
                        In the IKE-less case, the I2NSF Controller sends
                        the IPsec SA information to the NSF's SAD that
                        includes the private session keys required for
                        integrity and encryption. The I2NSF Controller
                        <span class="bcp14">MUST NOT</span> store the keys after 
                        distributing them. Moreover, the NSFs receiving
                        private key material <span class="bcp14">MUST NOT</span> allow the reading of
                        these values by any other entity (including the
                        I2NSF Controller itself) once they have been
                        applied (i.e., write-only operations) into the NSFs.
                        Nevertheless, if the attacker has access to the
                        I2NSF Controller during the period of time that
                        key material is generated, it may obtain these
                        values. In other words, the attacker might be able to
                        observe the IPsec traffic and decrypt, or even
                        modify and re-encrypt, the traffic between peers.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">Finally, the security association between the
                    I2NSF Controller and the NSFs <span class="bcp14">MUST</span> provide, at
                    least, the same degree of protection as the one
                    achieved by the IPsec SAs configured in the
                    NSFs. In particular, the security association
                    between the I2NSF Controller and the NSFs <span class="bcp14">MUST</span>
                    provide forward secrecy if this property is to
                    be achieved in the IPsec SAs that the I2NSF
                    Controller configures in the NSFs. Similarly,
                    the encryption algorithms used in the security
                    association between the I2NSF Controller and the NSF
                    <span class="bcp14">MUST</span> have, at least, the same strength (minimum
                    strength of a 128-bit key) as the algorithms
                    used to establish the IPsec SAs.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-yang">
<section id="section-7.3">
        <h3 id="name-yang-modules">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-yang-modules" class="section-name selfRef">YANG Modules</a>
        </h3>
<p id="section-7.3-1">The YANG modules specified in this document define a
                        schema for data that is designed to be accessed via
                        network management protocols such as NETCONF 
                        <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> or RESTCONF 
                        <span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span>. The lowest NETCONF layer
                        is the secure transport layer, and the
                        mandatory-to-implement secure transport is Secure Shell
                        (SSH) <span>[<a href="#RFC6242" class="xref">RFC6242</a>]</span>. The lowest RESTCONF
                        layer is HTTPS, and the mandatory-to-implement secure
                        transport is TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<p id="section-7.3-2">The Network Configuration Access Control Model (NACM) 
                        <span>[<a href="#RFC8341" class="xref">RFC8341</a>]</span> provides the means to restrict
                        access for particular NETCONF or RESTCONF users to a
                        preconfigured subset of all available NETCONF or
                        RESTCONF protocol operations and content.<a href="#section-7.3-2" class="pilcrow">¶</a></p>
<p id="section-7.3-3">There are a number of data nodes defined in these YANG
                        modules that are writable/creatable/deletable (i.e.,
                        config true, which is the default). These data nodes
                        may be considered sensitive or vulnerable in some
                        network environments. Write operations 
                        (e.g., edit-config) to these data nodes without 
                        proper protection can have a negative
                        effect on network operations. These are the subtrees and
                        data nodes and their sensitivity/vulnerability:<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-7.3-4">
          <dt id="section-7.3-4.1">For the IKE case (ietf-i2nsf-ike):</dt>
          <dd style="margin-left: 1.5em" id="section-7.3-4.2">
            <span class="break"></span><dl class="dlParallel" id="section-7.3-4.2.1">
              <dt id="section-7.3-4.2.1.1">/ipsec-ike:</dt>
              <dd style="margin-left: 1.5em" id="section-7.3-4.2.1.2">The entire container in this module
                            is sensitive to write operations. An attacker may
                            add/modify the credentials to be used for the
                            authentication (e.g., to impersonate an NSF), for the
                            trust root (e.g., changing the trusted CA
                            certificates), for the cryptographic algorithms
                            (allowing a downgrading attack), for the IPsec
                            policies (e.g., by allowing leaking of data traffic
                            by changing to an allow policy), and in general,
                            changing the IKE SA conditions and credentials
                            between any NSF.<a href="#section-7.3-4.2.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-7.3-4.3"> For the IKE-less case (ietf-i2nsf-ikeless):</dt>
          <dd style="margin-left: 1.5em" id="section-7.3-4.4">
            <span class="break"></span><dl class="dlParallel" id="section-7.3-4.4.1">
              <dt id="section-7.3-4.4.1.1">/ipsec-ikeless: </dt>
              <dd style="margin-left: 1.5em" id="section-7.3-4.4.1.2">The entire container in this
                            module is sensitive to write operations. An
                            attacker may add/modify/delete any IPsec policies
                            (e.g., by allowing leaking of data traffic by
                            changing to an allow policy) in the   
                            /ipsec-ikeless/spd container,
                            add/modify/delete any IPsec SAs between 
                            two NSF by means of /ipsec-ikeless/sad container,
                            and, in general, change any IPsec SAs and IPsec
                            policies between any NSF.<a href="#section-7.3-4.4.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-7.3-5">Some of the readable data nodes in these YANG modules may
                        be considered sensitive or vulnerable in some network
                        environments. It is thus important to control read
                        access (e.g., via get, get-config, or notification) to
                        these data nodes. These are the subtrees and data nodes
                        and their sensitivity/vulnerability:<a href="#section-7.3-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-7.3-6">
          <dt id="section-7.3-6.1"> For the IKE case (ietf-i2nsf-ike):</dt>
          <dd style="margin-left: 1.5em" id="section-7.3-6.2">
            <span class="break"></span><dl class="dlParallel" id="section-7.3-6.2.1">
              <dt id="section-7.3-6.2.1.1">/ipsec-ike/pad:</dt>
              <dd style="margin-left: 1.5em" id="section-7.3-6.2.1.2">This container includes sensitive
                                information to read operations. This information
                                <span class="bcp14">MUST NOT</span> be returned to a client. For
                                example, cryptographic material configured in
                                the NSFs (peer-authentication/pre-shared/secret and  peer-authentication/digital-signature/private-key) 
                                are already protected by the NACM
                                extension "default-deny-all" in this
                                document.<a href="#section-7.3-6.2.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-7.3-6.3"> For the IKE-less case (ietf-i2nsf-ikeless):</dt>
          <dd style="margin-left: 1.5em" id="section-7.3-6.4">
            <span class="break"></span><dl class="dlParallel" id="section-7.3-6.4.1">
              <dt id="section-7.3-6.4.1.1">/ipsec-ikeless/sad/sad-entry/ipsec-sa-config/esp-sa:</dt>
              <dd style="margin-left: 1.5em" id="section-7.3-6.4.1.2">This
                                container includes symmetric keys for the IPsec
                                SAs. For example, encryption/key contains an ESP
                                encryption key value and encryption/iv contains
                                an Initialization Vector value. Similarly,
                                integrity/key has an ESP
                                integrity key value. Those values <span class="bcp14">MUST NOT</span> be
                                read by anyone and are protected by the NACM
                                extension "default-deny-all" in this document.<a href="#section-7.3-6.4.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IANA-Method-Type">[IANA-Method-Type]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Method Type"</span>, <span>&lt;<a href="https://www.iana.org/assignments/eap-numbers/">https://www.iana.org/assignments/eap-numbers/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-Protocols-Number">[IANA-Protocols-Number]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Protocol Numbers"</span>, <span>&lt;<a href="https://www.iana.org/assignments/protocol-numbers/">https://www.iana.org/assignments/protocol-numbers/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IKEv2-Auth-Method">[IKEv2-Auth-Method]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"IKEv2 Authentication Method"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ikev2-parameters/">https://www.iana.org/assignments/ikev2-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IKEv2-Parameters">[IKEv2-Parameters]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Internet Key Exchange Version 2 (IKEv2) Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ikev2-parameters/">https://www.iana.org/assignments/ikev2-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IKEv2-Transform-Type-1">[IKEv2-Transform-Type-1]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Transform Type 1 - Encryption Algorithm Transform IDs"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ikev2-parameters/">https://www.iana.org/assignments/ikev2-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IKEv2-Transform-Type-3">[IKEv2-Transform-Type-3]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Transform Type 3 - Integrity Algorithm Transform IDs"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ikev2-parameters/">https://www.iana.org/assignments/ikev2-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IKEv2-Transform-Type-4">[IKEv2-Transform-Type-4]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Transform Type 4 - Diffie-Hellman Group Transform IDs"</span>, <span>&lt;<a href="https://www.iana.org/assignments/ikev2-parameters/">https://www.iana.org/assignments/ikev2-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ITU-T.X.690">[ITU-T.X.690]</dt>
        <dd>
<span class="refAuthor">International Telecommunication Union</span>, <span class="refTitle">"Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"</span>, <span class="refContent">ITU-T Recommendation X.690</span>, <span class="refContent">ISO/IEC 8825-1</span>, <time datetime="2021-02" class="refDate">February 2021</time>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3947">[RFC3947]</dt>
        <dd>
<span class="refAuthor">Kivinen, T.</span>, <span class="refAuthor">Swander, B.</span>, <span class="refAuthor">Huttunen, A.</span>, and <span class="refAuthor">V. Volpe</span>, <span class="refTitle">"Negotiation of NAT-Traversal in the IKE"</span>, <span class="seriesInfo">RFC 3947</span>, <span class="seriesInfo">DOI 10.17487/RFC3947</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3947">https://www.rfc-editor.org/info/rfc3947</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3948">[RFC3948]</dt>
        <dd>
<span class="refAuthor">Huttunen, A.</span>, <span class="refAuthor">Swander, B.</span>, <span class="refAuthor">Volpe, V.</span>, <span class="refAuthor">DiBurro, L.</span>, and <span class="refAuthor">M. Stenberg</span>, <span class="refTitle">"UDP Encapsulation of IPsec ESP Packets"</span>, <span class="seriesInfo">RFC 3948</span>, <span class="seriesInfo">DOI 10.17487/RFC3948</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3948">https://www.rfc-editor.org/info/rfc3948</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4301">[RFC4301]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span> and <span class="refAuthor">K. Seo</span>, <span class="refTitle">"Security Architecture for the Internet Protocol"</span>, <span class="seriesInfo">RFC 4301</span>, <span class="seriesInfo">DOI 10.17487/RFC4301</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4301">https://www.rfc-editor.org/info/rfc4301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4303">[RFC4303]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4303</span>, <span class="seriesInfo">DOI 10.17487/RFC4303</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4303">https://www.rfc-editor.org/info/rfc4303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span>, <span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Boeyen, S.</span>, <span class="refAuthor">Housley, R.</span>, and <span class="refAuthor">W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5322">[RFC5322]</dt>
        <dd>
<span class="refAuthor">Resnick, P., Ed.</span>, <span class="refTitle">"Internet Message Format"</span>, <span class="seriesInfo">RFC 5322</span>, <span class="seriesInfo">DOI 10.17487/RFC5322</span>, <time datetime="2008-10" class="refDate">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5322">https://www.rfc-editor.org/info/rfc5322</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5915">[RFC5915]</dt>
        <dd>
<span class="refAuthor">Turner, S.</span> and <span class="refAuthor">D. Brown</span>, <span class="refTitle">"Elliptic Curve Private Key Structure"</span>, <span class="seriesInfo">RFC 5915</span>, <span class="seriesInfo">DOI 10.17487/RFC5915</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5915">https://www.rfc-editor.org/info/rfc5915</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6020">[RFC6020]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6020</span>, <span class="seriesInfo">DOI 10.17487/RFC6020</span>, <time datetime="2010-10" class="refDate">October 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6020">https://www.rfc-editor.org/info/rfc6020</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6241">[RFC6241]</dt>
        <dd>
<span class="refAuthor">Enns, R., Ed.</span>, <span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refAuthor">Schoenwaelder, J., Ed.</span>, and <span class="refAuthor">A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6242">[RFC6242]</dt>
        <dd>
<span class="refAuthor">Wasserman, M.</span>, <span class="refTitle">"Using the NETCONF Protocol over Secure Shell (SSH)"</span>, <span class="seriesInfo">RFC 6242</span>, <span class="seriesInfo">DOI 10.17487/RFC6242</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6242">https://www.rfc-editor.org/info/rfc6242</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6960">[RFC6960]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Myers, M.</span>, <span class="refAuthor">Ankney, R.</span>, <span class="refAuthor">Malpani, A.</span>, <span class="refAuthor">Galperin, S.</span>, and <span class="refAuthor">C. Adams</span>, <span class="refTitle">"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"</span>, <span class="seriesInfo">RFC 6960</span>, <span class="seriesInfo">DOI 10.17487/RFC6960</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6960">https://www.rfc-editor.org/info/rfc6960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6991">[RFC6991]</dt>
        <dd>
<span class="refAuthor">Schoenwaelder, J., Ed.</span>, <span class="refTitle">"Common YANG Data Types"</span>, <span class="seriesInfo">RFC 6991</span>, <span class="seriesInfo">DOI 10.17487/RFC6991</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6991">https://www.rfc-editor.org/info/rfc6991</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7296">[RFC7296]</dt>
        <dd>
<span class="refAuthor">Kaufman, C.</span>, <span class="refAuthor">Hoffman, P.</span>, <span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Eronen, P.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">STD 79</span>, <span class="seriesInfo">RFC 7296</span>, <span class="seriesInfo">DOI 10.17487/RFC7296</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7296">https://www.rfc-editor.org/info/rfc7296</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7383">[RFC7383]</dt>
        <dd>
<span class="refAuthor">Smyslov, V.</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation"</span>, <span class="seriesInfo">RFC 7383</span>, <span class="seriesInfo">DOI 10.17487/RFC7383</span>, <time datetime="2014-11" class="refDate">November 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7383">https://www.rfc-editor.org/info/rfc7383</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7427">[RFC7427]</dt>
        <dd>
<span class="refAuthor">Kivinen, T.</span> and <span class="refAuthor">J. Snyder</span>, <span class="refTitle">"Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 7427</span>, <span class="seriesInfo">DOI 10.17487/RFC7427</span>, <time datetime="2015-01" class="refDate">January 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7427">https://www.rfc-editor.org/info/rfc7427</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7619">[RFC7619]</dt>
        <dd>
<span class="refAuthor">Smyslov, V.</span> and <span class="refAuthor">P. Wouters</span>, <span class="refTitle">"The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 7619</span>, <span class="seriesInfo">DOI 10.17487/RFC7619</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7619">https://www.rfc-editor.org/info/rfc7619</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7950">[RFC7950]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"The YANG 1.1 Data Modeling Language"</span>, <span class="seriesInfo">RFC 7950</span>, <span class="seriesInfo">DOI 10.17487/RFC7950</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7950">https://www.rfc-editor.org/info/rfc7950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8017">[RFC8017]</dt>
        <dd>
<span class="refAuthor">Moriarty, K., Ed.</span>, <span class="refAuthor">Kaliski, B.</span>, <span class="refAuthor">Jonsson, J.</span>, and <span class="refAuthor">A. Rusch</span>, <span class="refTitle">"PKCS #1: RSA Cryptography Specifications Version 2.2"</span>, <span class="seriesInfo">RFC 8017</span>, <span class="seriesInfo">DOI 10.17487/RFC8017</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8017">https://www.rfc-editor.org/info/rfc8017</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8040">[RFC8040]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span>, <span class="refAuthor">Bjorklund, M.</span>, and <span class="refAuthor">K. Watsen</span>, <span class="refTitle">"RESTCONF Protocol"</span>, <span class="seriesInfo">RFC 8040</span>, <span class="seriesInfo">DOI 10.17487/RFC8040</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8040">https://www.rfc-editor.org/info/rfc8040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8221">[RFC8221]</dt>
        <dd>
<span class="refAuthor">Wouters, P.</span>, <span class="refAuthor">Migault, D.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Nir, Y.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)"</span>, <span class="seriesInfo">RFC 8221</span>, <span class="seriesInfo">DOI 10.17487/RFC8221</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8221">https://www.rfc-editor.org/info/rfc8221</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8229">[RFC8229]</dt>
        <dd>
<span class="refAuthor">Pauly, T.</span>, <span class="refAuthor">Touati, S.</span>, and <span class="refAuthor">R. Mantha</span>, <span class="refTitle">"TCP Encapsulation of IKE and IPsec Packets"</span>, <span class="seriesInfo">RFC 8229</span>, <span class="seriesInfo">DOI 10.17487/RFC8229</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8229">https://www.rfc-editor.org/info/rfc8229</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8247">[RFC8247]</dt>
        <dd>
<span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Kivinen, T.</span>, <span class="refAuthor">Wouters, P.</span>, and <span class="refAuthor">D. Migault</span>, <span class="refTitle">"Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">RFC 8247</span>, <span class="seriesInfo">DOI 10.17487/RFC8247</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8247">https://www.rfc-editor.org/info/rfc8247</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8340">[RFC8340]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span> and <span class="refAuthor">L. Berger, Ed.</span>, <span class="refTitle">"YANG Tree Diagrams"</span>, <span class="seriesInfo">BCP 215</span>, <span class="seriesInfo">RFC 8340</span>, <span class="seriesInfo">DOI 10.17487/RFC8340</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8340">https://www.rfc-editor.org/info/rfc8340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8341">[RFC8341]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span> and <span class="refAuthor">M. Bjorklund</span>, <span class="refTitle">"Network Configuration Access Control Model"</span>, <span class="seriesInfo">STD 91</span>, <span class="seriesInfo">RFC 8341</span>, <span class="seriesInfo">DOI 10.17487/RFC8341</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8341">https://www.rfc-editor.org/info/rfc8341</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8342">[RFC8342]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span>, <span class="refAuthor">Schoenwaelder, J.</span>, <span class="refAuthor">Shafer, P.</span>, <span class="refAuthor">Watsen, K.</span>, and <span class="refAuthor">R. Wilton</span>, <span class="refTitle">"Network Management Datastore Architecture (NMDA)"</span>, <span class="seriesInfo">RFC 8342</span>, <span class="seriesInfo">DOI 10.17487/RFC8342</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8342">https://www.rfc-editor.org/info/rfc8342</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.carrel-ipsecme-controller-ike">[IPSECME-CONTROLLER-IKE]</dt>
        <dd>
<span class="refAuthor">Carrel, D.</span> and <span class="refAuthor">B. Weis</span>, <span class="refTitle">"IPsec Key Exchange using a Controller"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-carrel-ipsecme-controller-ike-01</span>, <time datetime="2019-03-10" class="refDate">10 March 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01">https://datatracker.ietf.org/doc/html/draft-carrel-ipsecme-controller-ike-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ITU-T.Y.3300">[ITU-T.Y.3300]</dt>
        <dd>
<span class="refAuthor">International Telecommunications Union</span>, <span class="refTitle">"Y.3300: Framework of software-defined networking"</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.itu.int/rec/T-REC-Y.3300/en">https://www.itu.int/rec/T-REC-Y.3300/en</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="libreswan">[libreswan]</dt>
        <dd>
<span class="refAuthor">The Libreswan Project</span>, <span class="refTitle">"Libreswan VPN software"</span>, <span>&lt;<a href="https://libreswan.org/">https://libreswan.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="netconf-vpn">[netconf-vpn]</dt>
        <dd>
<span class="refAuthor">Stefan Wallin</span>, <span class="refTitle">"Tutorial: NETCONF and YANG"</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://ripe68.ripe.net/presentations/181-NETCONF-YANG-tutorial-43.pdf">https://ripe68.ripe.net/presentations/181-NETCONF-YANG-tutorial-43.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ONF-OpenFlow">[ONF-OpenFlow]</dt>
        <dd>
<span class="refAuthor">Open Networking Foundation</span>, <span class="refTitle">"OpenFlow Switch Specification"</span>, <span class="seriesInfo">Version 1.4.0 (Wire Protocol 0x05)</span>, <time datetime="2013-10" class="refDate">October 2013</time>, <span>&lt;<a href="https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf">https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.4.0.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ONF-SDN-Architecture">[ONF-SDN-Architecture]</dt>
        <dd>
<span class="refAuthor">Open Networking Foundation</span>, <span class="refTitle">"SDN architecture"</span>, <span class="seriesInfo">Issue 1</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.opennetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf">https://www.opennetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2367">[RFC2367]</dt>
        <dd>
<span class="refAuthor">McDonald, D.</span>, <span class="refAuthor">Metz, C.</span>, and <span class="refAuthor">B. Phan</span>, <span class="refTitle">"PF_KEY Key Management API, Version 2"</span>, <span class="seriesInfo">RFC 2367</span>, <span class="seriesInfo">DOI 10.17487/RFC2367</span>, <time datetime="1998-07" class="refDate">July 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2367">https://www.rfc-editor.org/info/rfc2367</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3688">[RFC3688]</dt>
        <dd>
<span class="refAuthor">Mealling, M.</span>, <span class="refTitle">"The IETF XML Registry"</span>, <span class="seriesInfo">BCP 81</span>, <span class="seriesInfo">RFC 3688</span>, <span class="seriesInfo">DOI 10.17487/RFC3688</span>, <time datetime="2004-01" class="refDate">January 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3688">https://www.rfc-editor.org/info/rfc3688</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6040">[RFC6040]</dt>
        <dd>
<span class="refAuthor">Briscoe, B.</span>, <span class="refTitle">"Tunnelling of Explicit Congestion Notification"</span>, <span class="seriesInfo">RFC 6040</span>, <span class="seriesInfo">DOI 10.17487/RFC6040</span>, <time datetime="2010-11" class="refDate">November 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6040">https://www.rfc-editor.org/info/rfc6040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6071">[RFC6071]</dt>
        <dd>
<span class="refAuthor">Frankel, S.</span> and <span class="refAuthor">S. Krishnan</span>, <span class="refTitle">"IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap"</span>, <span class="seriesInfo">RFC 6071</span>, <span class="seriesInfo">DOI 10.17487/RFC6071</span>, <time datetime="2011-02" class="refDate">February 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6071">https://www.rfc-editor.org/info/rfc6071</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6437">[RFC6437]</dt>
        <dd>
<span class="refAuthor">Amante, S.</span>, <span class="refAuthor">Carpenter, B.</span>, <span class="refAuthor">Jiang, S.</span>, and <span class="refAuthor">J. Rajahalme</span>, <span class="refTitle">"IPv6 Flow Label Specification"</span>, <span class="seriesInfo">RFC 6437</span>, <span class="seriesInfo">DOI 10.17487/RFC6437</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6437">https://www.rfc-editor.org/info/rfc6437</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7149">[RFC7149]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span> and <span class="refAuthor">C. Jacquenet</span>, <span class="refTitle">"Software-Defined Networking: A Perspective from within a Service Provider Environment"</span>, <span class="seriesInfo">RFC 7149</span>, <span class="seriesInfo">DOI 10.17487/RFC7149</span>, <time datetime="2014-03" class="refDate">March 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7149">https://www.rfc-editor.org/info/rfc7149</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7426">[RFC7426]</dt>
        <dd>
<span class="refAuthor">Haleplidis, E., Ed.</span>, <span class="refAuthor">Pentikousis, K., Ed.</span>, <span class="refAuthor">Denazis, S.</span>, <span class="refAuthor">Hadi Salim, J.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">O. Koufopavlou</span>, <span class="refTitle">"Software-Defined Networking (SDN): Layers and Architecture Terminology"</span>, <span class="seriesInfo">RFC 7426</span>, <span class="seriesInfo">DOI 10.17487/RFC7426</span>, <time datetime="2015-01" class="refDate">January 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7426">https://www.rfc-editor.org/info/rfc7426</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8192">[RFC8192]</dt>
        <dd>
<span class="refAuthor">Hares, S.</span>, <span class="refAuthor">Lopez, D.</span>, <span class="refAuthor">Zarny, M.</span>, <span class="refAuthor">Jacquenet, C.</span>, <span class="refAuthor">Kumar, R.</span>, and <span class="refAuthor">J. Jeong</span>, <span class="refTitle">"Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases"</span>, <span class="seriesInfo">RFC 8192</span>, <span class="seriesInfo">DOI 10.17487/RFC8192</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8192">https://www.rfc-editor.org/info/rfc8192</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8329">[RFC8329]</dt>
        <dd>
<span class="refAuthor">Lopez, D.</span>, <span class="refAuthor">Lopez, E.</span>, <span class="refAuthor">Dunbar, L.</span>, <span class="refAuthor">Strassner, J.</span>, and <span class="refAuthor">R. Kumar</span>, <span class="refTitle">"Framework for Interface to Network Security Functions"</span>, <span class="seriesInfo">RFC 8329</span>, <span class="seriesInfo">DOI 10.17487/RFC8329</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8329">https://www.rfc-editor.org/info/rfc8329</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SDNSecServ">[SDNSecServ]</dt>
        <dd>
<span class="refAuthor">Scott-Hayward, S.</span>, <span class="refAuthor">O'Callaghan, G.</span>, and <span class="refAuthor">P. Sezer</span>, <span class="refTitle">"Sdn Security: A Survey"</span>, <span class="refContent">2013 IEEE SDN for Future Networks and Services (SDN4FNS), pp. 1-7</span>, <span class="seriesInfo">DOI 10.1109/SDN4FNS.2013.6702553</span>, <time datetime="2013-11" class="refDate">November 2013</time>, <span>&lt;<a href="https://doi.org/10.1109/SDN4FNS.2013.6702553">https://doi.org/10.1109/SDN4FNS.2013.6702553</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SDNSecurity">[SDNSecurity]</dt>
        <dd>
<span class="refAuthor">Kreutz, D.</span>, <span class="refAuthor">Ramos, F.</span>, and <span class="refAuthor">P. Verissimo</span>, <span class="refTitle">"Towards secure and dependable software-defined networks"</span>, <span class="refContent">Proceedings of the second ACM SIGCOMM workshop on Hot Topics in software defined networking, pp. 55-60</span>, <span class="seriesInfo">DOI 10.1145/2491185.2491199</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span>&lt;<a href="https://doi.org/10.1145/2491185.2491199">https://doi.org/10.1145/2491185.2491199</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="strongswan">[strongswan]</dt>
        <dd>
<span class="refAuthor">CESNET</span>, <span class="refTitle">"strongSwan: the OpenSource IPsec-based VPN Solution"</span>, <span>&lt;<a href="https://www.strongswan.org/">https://www.strongswan.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.tran-ipsecme-yang">[TRAN-IPSECME-YANG]</dt>
      <dd>
<span class="refAuthor">Tran, K.</span>, <span class="refAuthor">Wang, H.</span>, <span class="refAuthor">Nagaraj, V. K.</span>, and <span class="refAuthor">X. Chen</span>, <span class="refTitle">"Yang Data Model for Internet Protocol Security (IPsec)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-tran-ipsecme-yang-01</span>, <time datetime="2016-03-18" class="refDate">18 March 2016</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-tran-ipsecme-yang-01">https://datatracker.ietf.org/doc/html/draft-tran-ipsecme-yang-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="appendix-d">
<section id="appendix-A">
      <h2 id="name-xml-configuration-example-f">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-xml-configuration-example-f" class="section-name selfRef">XML Configuration Example for IKE Case (Gateway-to-Gateway)</a>
      </h2>
<p id="appendix-A-1">This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see <a href="#fig_example-ike" class="xref">Figure 3</a>) in tunnel mode (gateway-to-gateway) with ESP, with authentication based on X.509 certificates (simplified for brevity with "base64encodedvalue==") and applying the IKE case.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<span id="name-ike-case-tunnel-mode-x509-c"></span><div id="fig_example-ike">
<figure id="figure-3">
        <div class="artwork art-text alignCenter" id="appendix-A-2.1">
<pre>
                          +------------------+
                          | I2NSF Controller |
                          +------------------+
                   I2NSF NSF-Facing |
                          Interface |
                  /-----------------+---------------\
                 /                                   \
                /                                     \
   +----+  +--------+                            +--------+  +----+
   | h1 |--| nsf_h1 |== IPsec_ESP_Tunnel_mode == | nsf_h2 |--| h2 |
   +----+  +--------+                            +--------+  +----+
          :1        :100                       :200       :1

(2001:db8:1:/64)          (2001:db8:123:/64)       (2001:db8:2:/64)
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-ike-case-tunnel-mode-x509-c" class="selfRef">IKE Case, Tunnel Mode, X.509 Certificate Authentication</a>
        </figcaption></figure>
</div>
<div id="appendix-A-3">
<pre class="sourcecode lang-xml">
&lt;ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
  &lt;pad&gt;
    &lt;pad-entry&gt;
      &lt;name&gt;nsf_h1_pad&lt;/name&gt;
      &lt;ipv6-address&gt;2001:db8:123::100&lt;/ipv6-address&gt;
      &lt;peer-authentication&gt;
         &lt;auth-method&gt;digital-signature&lt;/auth-method&gt;
         &lt;digital-signature&gt;
            &lt;cert-data&gt;base64encodedvalue==&lt;/cert-data&gt;
            &lt;private-key&gt;base64encodedvalue==&lt;/private-key&gt;
            &lt;ca-data&gt;base64encodedvalue==&lt;/ca-data&gt;
         &lt;/digital-signature&gt;
      &lt;/peer-authentication&gt;
    &lt;/pad-entry&gt;
    &lt;pad-entry&gt;
      &lt;name&gt;nsf_h2_pad&lt;/name&gt;
      &lt;ipv6-address&gt;2001:db8:123::200&lt;/ipv6-address&gt;
      &lt;auth-protocol&gt;ikev2&lt;/auth-protocol&gt;
      &lt;peer-authentication&gt;
        &lt;auth-method&gt;digital-signature&lt;/auth-method&gt;
        &lt;digital-signature&gt;
          &lt;!-- RSA Digital Signature --&gt;
          &lt;ds-algorithm&gt;1&lt;/ds-algorithm&gt;
          &lt;cert-data&gt;base64encodedvalue==&lt;/cert-data&gt;
          &lt;ca-data&gt;base64encodedvalue==&lt;/ca-data&gt;
        &lt;/digital-signature&gt;
      &lt;/peer-authentication&gt;
    &lt;/pad-entry&gt;
  &lt;/pad&gt;
  &lt;conn-entry&gt;
     &lt;name&gt;nsf_h1-nsf_h2&lt;/name&gt;
     &lt;autostartup&gt;start&lt;/autostartup&gt;
     &lt;version&gt;ikev2&lt;/version&gt;
     &lt;initial-contact&gt;false&lt;/initial-contact&gt;
     &lt;fragmentation&gt;&lt;enabled&gt;false&lt;/enabled&gt;&lt;/fragmentation&gt;
     &lt;ike-sa-lifetime-soft&gt;
        &lt;rekey-time&gt;60&lt;/rekey-time&gt;
        &lt;reauth-time&gt;120&lt;/reauth-time&gt;
     &lt;/ike-sa-lifetime-soft&gt;
     &lt;ike-sa-lifetime-hard&gt;
        &lt;over-time&gt;3600&lt;/over-time&gt;
     &lt;/ike-sa-lifetime-hard&gt;
     &lt;!--AUTH_HMAC_SHA2_512_256--&gt;
     &lt;ike-sa-intr-alg&gt;14&lt;/ike-sa-intr-alg&gt;
     &lt;!--ENCR_AES_CBC - 128 bits--&gt;
     &lt;ike-sa-encr-alg&gt;
        &lt;id&gt;1&lt;/id&gt;
     &lt;/ike-sa-encr-alg&gt;
     &lt;!--8192-bit MODP Group--&gt;
     &lt;dh-group&gt;18&lt;/dh-group&gt;
     &lt;half-open-ike-sa-timer&gt;30&lt;/half-open-ike-sa-timer&gt;
     &lt;half-open-ike-sa-cookie-threshold&gt;
        15
     &lt;/half-open-ike-sa-cookie-threshold&gt;
     &lt;local&gt;
         &lt;local-pad-entry-name&gt;nsf_h1_pad&lt;/local-pad-entry-name&gt;
     &lt;/local&gt;
     &lt;remote&gt;
         &lt;remote-pad-entry-name&gt;nsf_h2_pad&lt;/remote-pad-entry-name&gt;
     &lt;/remote&gt;
     &lt;spd&gt;
       &lt;spd-entry&gt;
          &lt;name&gt;nsf_h1-nsf_h2&lt;/name&gt;
          &lt;ipsec-policy-config&gt;
            &lt;anti-replay-window-size&gt;64&lt;/anti-replay-window-size&gt;
            &lt;traffic-selector&gt;
               &lt;local-prefix&gt;2001:db8:1::0/64&lt;/local-prefix&gt;
               &lt;remote-prefix&gt;2001:db8:2::0/64&lt;/remote-prefix&gt;
               &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
            &lt;/traffic-selector&gt;
            &lt;processing-info&gt;
               &lt;action&gt;protect&lt;/action&gt;
               &lt;ipsec-sa-cfg&gt;
                  &lt;pfp-flag&gt;false&lt;/pfp-flag&gt;
                  &lt;ext-seq-num&gt;true&lt;/ext-seq-num&gt;
                  &lt;seq-overflow&gt;false&lt;/seq-overflow&gt;
                  &lt;stateful-frag-check&gt;false&lt;/stateful-frag-check&gt;
                  &lt;mode&gt;tunnel&lt;/mode&gt;
                  &lt;protocol-parameters&gt;esp&lt;/protocol-parameters&gt;
                  &lt;esp-algorithms&gt;
                     &lt;!-- AUTH_HMAC_SHA1_96 --&gt;
                     &lt;integrity&gt;2&lt;/integrity&gt;
                      &lt;encryption&gt;
                          &lt;!-- ENCR_AES_CBC --&gt;
                          &lt;id&gt;1&lt;/id&gt;
                          &lt;algorithm-type&gt;12&lt;/algorithm-type&gt;
                          &lt;key-length&gt;128&lt;/key-length&gt;
                      &lt;/encryption&gt;
                      &lt;encryption&gt;
                          &lt;!-- ENCR_3DES--&gt;
                          &lt;id&gt;2&lt;/id&gt;
                          &lt;algorithm-type&gt;3&lt;/algorithm-type&gt;
                      &lt;/encryption&gt;
                     &lt;tfc-pad&gt;false&lt;/tfc-pad&gt;
                  &lt;/esp-algorithms&gt;
                  &lt;tunnel&gt;
                     &lt;local&gt;2001:db8:123::100&lt;/local&gt;
                     &lt;remote&gt;2001:db8:123::200&lt;/remote&gt;
                     &lt;df-bit&gt;clear&lt;/df-bit&gt;
                     &lt;bypass-dscp&gt;true&lt;/bypass-dscp&gt;
                 &lt;/tunnel&gt;
               &lt;/ipsec-sa-cfg&gt;
            &lt;/processing-info&gt;
          &lt;/ipsec-policy-config&gt;
       &lt;/spd-entry&gt;
     &lt;/spd&gt;
     &lt;child-sa-info&gt;
        &lt;!--8192-bit MODP Group --&gt;
        &lt;fs-groups&gt;18&lt;/fs-groups&gt;
        &lt;child-sa-lifetime-soft&gt;
           &lt;bytes&gt;1000000&lt;/bytes&gt;
           &lt;packets&gt;1000&lt;/packets&gt;
           &lt;time&gt;30&lt;/time&gt;
           &lt;idle&gt;60&lt;/idle&gt;
           &lt;action&gt;replace&lt;/action&gt;
        &lt;/child-sa-lifetime-soft&gt;
        &lt;child-sa-lifetime-hard&gt;
           &lt;bytes&gt;2000000&lt;/bytes&gt;
           &lt;packets&gt;2000&lt;/packets&gt;
           &lt;time&gt;60&lt;/time&gt;
           &lt;idle&gt;120&lt;/idle&gt;
        &lt;/child-sa-lifetime-hard&gt;
     &lt;/child-sa-info&gt;
   &lt;/conn-entry&gt;
&lt;/ipsec-ike&gt;
</pre><a href="#appendix-A-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="appendix-e">
<section id="appendix-B">
      <h2 id="name-xml-configuration-example-fo">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-xml-configuration-example-fo" class="section-name selfRef">XML Configuration Example for IKE-less Case (Host-to-Host)</a>
      </h2>
<p id="appendix-B-1">This example shows an XML configuration file sent by the I2NSF Controller to establish an IPsec SA between two NSFs (see <a href="#fig_example-ikeless" class="xref">Figure 4</a>) in transport mode (host-to-host) with ESP in the IKE-less case.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<span id="name-ike-less-case-transport-mod"></span><div id="fig_example-ikeless">
<figure id="figure-4">
        <div class="artwork art-text alignCenter" id="appendix-B-2.1">
<pre>
                   +------------------+
                   | I2NSF Controller |
                   +------------------+
           I2NSF NSF-Facing |
                  Interface |
       /--------------------+-------------------\
      /                                          \
     /                                            \
+--------+                                    +--------+
| nsf_h1 |===== IPsec_ESP_Transport_mode =====| nsf_h2 |
+--------+                                    +--------+
        :100        (2001:db8:123:/64)       :200
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-ike-less-case-transport-mod" class="selfRef">IKE-less Case, Transport Mode</a>
        </figcaption></figure>
</div>
<div id="appendix-B-3">
<pre class="sourcecode lang-xml">
&lt;ipsec-ikeless
  xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"
  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;
  &lt;spd&gt;
    &lt;spd-entry&gt;
        &lt;name&gt;
           in/trans/2001:db8:123::200/2001:db8:123::100
        &lt;/name&gt;
        &lt;direction&gt;inbound&lt;/direction&gt;
        &lt;reqid&gt;1&lt;/reqid&gt;
        &lt;ipsec-policy-config&gt;
           &lt;traffic-selector&gt;
             &lt;local-prefix&gt;2001:db8:123::200/128&lt;/local-prefix&gt;
             &lt;remote-prefix&gt;2001:db8:123::100/128&lt;/remote-prefix&gt;
             &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
           &lt;/traffic-selector&gt;
           &lt;processing-info&gt;
              &lt;action&gt;protect&lt;/action&gt;
              &lt;ipsec-sa-cfg&gt;
                &lt;ext-seq-num&gt;true&lt;/ext-seq-num&gt;
                &lt;seq-overflow&gt;false&lt;/seq-overflow&gt;
                &lt;mode&gt;transport&lt;/mode&gt;
                &lt;protocol-parameters&gt;esp&lt;/protocol-parameters&gt;
                &lt;esp-algorithms&gt;
                   &lt;!--AUTH_HMAC_SHA1_96--&gt;
                   &lt;integrity&gt;2&lt;/integrity&gt;
                   &lt;!--ENCR_AES_CBC --&gt;
                   &lt;encryption&gt;
                     &lt;id&gt;1&lt;/id&gt;
                     &lt;algorithm-type&gt;12&lt;/algorithm-type&gt;
                      &lt;key-length&gt;128&lt;/key-length&gt;
                   &lt;/encryption&gt;
                   &lt;encryption&gt;
                     &lt;id&gt;2&lt;/id&gt;
                     &lt;algorithm-type&gt;3&lt;/algorithm-type&gt;
                   &lt;/encryption&gt;
                &lt;/esp-algorithms&gt;
              &lt;/ipsec-sa-cfg&gt;
            &lt;/processing-info&gt;
          &lt;/ipsec-policy-config&gt;
        &lt;/spd-entry&gt;
        &lt;spd-entry&gt;
          &lt;name&gt;out/trans/2001:db8:123::100/2001:db8:123::200&lt;/name&gt;
          &lt;direction&gt;outbound&lt;/direction&gt;
          &lt;reqid&gt;1&lt;/reqid&gt;
          &lt;ipsec-policy-config&gt;
            &lt;traffic-selector&gt;
              &lt;local-prefix&gt;2001:db8:123::100/128&lt;/local-prefix&gt;
              &lt;remote-prefix&gt;2001:db8:123::200/128&lt;/remote-prefix&gt;
              &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
            &lt;/traffic-selector&gt;
            &lt;processing-info&gt;
              &lt;action&gt;protect&lt;/action&gt;
              &lt;ipsec-sa-cfg&gt;
                &lt;ext-seq-num&gt;true&lt;/ext-seq-num&gt;
                &lt;seq-overflow&gt;false&lt;/seq-overflow&gt;
                &lt;mode&gt;transport&lt;/mode&gt;
                &lt;protocol-parameters&gt;esp&lt;/protocol-parameters&gt;
                &lt;esp-algorithms&gt;
                  &lt;!-- AUTH_HMAC_SHA1_96 --&gt;
                  &lt;integrity&gt;2&lt;/integrity&gt;
                  &lt;!-- ENCR_AES_CBC --&gt;
                  &lt;encryption&gt;
                     &lt;id&gt;1&lt;/id&gt;
                     &lt;algorithm-type&gt;12&lt;/algorithm-type&gt;
                     &lt;key-length&gt;128&lt;/key-length&gt;
                  &lt;/encryption&gt;
                  &lt;encryption&gt;
                     &lt;id&gt;2&lt;/id&gt;
                     &lt;algorithm-type&gt;3&lt;/algorithm-type&gt;
                  &lt;/encryption&gt;
                &lt;/esp-algorithms&gt;
               &lt;/ipsec-sa-cfg&gt;
             &lt;/processing-info&gt;
           &lt;/ipsec-policy-config&gt;
        &lt;/spd-entry&gt;
     &lt;/spd&gt;
     &lt;sad&gt;
       &lt;sad-entry&gt;
         &lt;name&gt;out/trans/2001:db8:123::100/2001:db8:123::200&lt;/name&gt;
         &lt;reqid&gt;1&lt;/reqid&gt;
         &lt;ipsec-sa-config&gt;
            &lt;spi&gt;34501&lt;/spi&gt;
            &lt;ext-seq-num&gt;true&lt;/ext-seq-num&gt;
            &lt;seq-overflow&gt;false&lt;/seq-overflow&gt;
            &lt;anti-replay-window-size&gt;64&lt;/anti-replay-window-size&gt;
            &lt;traffic-selector&gt;
              &lt;local-prefix&gt;2001:db8:123::100/128&lt;/local-prefix&gt;
              &lt;remote-prefix&gt;2001:db8:123::200/128&lt;/remote-prefix&gt;
                 &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
             &lt;/traffic-selector&gt;
             &lt;protocol-parameters&gt;esp&lt;/protocol-parameters&gt;
             &lt;mode&gt;transport&lt;/mode&gt;
             &lt;esp-sa&gt;
               &lt;encryption&gt;
                  &lt;!-- //ENCR_AES_CBC --&gt;
                  &lt;encryption-algorithm&gt;12&lt;/encryption-algorithm&gt;
                  &lt;key&gt;01:23:45:67:89:AB:CE:DF&lt;/key&gt;
                  &lt;iv&gt;01:23:45:67:89:AB:CE:DF&lt;/iv&gt;
               &lt;/encryption&gt;
               &lt;integrity&gt;
                  &lt;!-- //AUTH_HMAC_SHA1_96 --&gt;
                  &lt;integrity-algorithm&gt;2&lt;/integrity-algorithm&gt;
                  &lt;key&gt;01:23:45:67:89:AB:CE:DF&lt;/key&gt;
               &lt;/integrity&gt;
             &lt;/esp-sa&gt;
         &lt;/ipsec-sa-config&gt;
       &lt;/sad-entry&gt;
       &lt;sad-entry&gt;
          &lt;name&gt;in/trans/2001:db8:123::200/2001:db8:123::100&lt;/name&gt;
          &lt;reqid&gt;1&lt;/reqid&gt;
          &lt;ipsec-sa-config&gt;
              &lt;spi&gt;34502&lt;/spi&gt;
              &lt;ext-seq-num&gt;true&lt;/ext-seq-num&gt;
              &lt;seq-overflow&gt;false&lt;/seq-overflow&gt;
              &lt;anti-replay-window-size&gt;64&lt;/anti-replay-window-size&gt;
              &lt;traffic-selector&gt;
                 &lt;local-prefix&gt;2001:db8:123::200/128&lt;/local-prefix&gt;
                 &lt;remote-prefix&gt;2001:db8:123::100/128&lt;/remote-prefix&gt;
                 &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
              &lt;/traffic-selector&gt;
              &lt;protocol-parameters&gt;esp&lt;/protocol-parameters&gt;
              &lt;mode&gt;transport&lt;/mode&gt;
              &lt;esp-sa&gt;
                 &lt;encryption&gt;
                    &lt;!-- //ENCR_AES_CBC --&gt;
                    &lt;encryption-algorithm&gt;12&lt;/encryption-algorithm&gt;
                    &lt;key&gt;01:23:45:67:89:AB:CE:DF&lt;/key&gt;
                    &lt;iv&gt;01:23:45:67:89:AB:CE:DF&lt;/iv&gt;
                 &lt;/encryption&gt;
                 &lt;integrity&gt;
                    &lt;!-- //AUTH_HMAC_SHA1_96 --&gt;
                    &lt;integrity-algorithm&gt;2&lt;/integrity-algorithm&gt;
                    &lt;key&gt;01:23:45:67:89:AB:CE:DF&lt;/key&gt;
                 &lt;/integrity&gt;
               &lt;/esp-sa&gt;
               &lt;sa-lifetime-hard&gt;
                  &lt;bytes&gt;2000000&lt;/bytes&gt;
                  &lt;packets&gt;2000&lt;/packets&gt;
                  &lt;time&gt;60&lt;/time&gt;
                  &lt;idle&gt;120&lt;/idle&gt;
               &lt;/sa-lifetime-hard&gt;
               &lt;sa-lifetime-soft&gt;
                  &lt;bytes&gt;1000000&lt;/bytes&gt;
                  &lt;packets&gt;1000&lt;/packets&gt;
                  &lt;time&gt;30&lt;/time&gt;
                  &lt;idle&gt;60&lt;/idle&gt;
                  &lt;action&gt;replace&lt;/action&gt;
               &lt;/sa-lifetime-soft&gt;
         &lt;/ipsec-sa-config&gt;
       &lt;/sad-entry&gt;
    &lt;/sad&gt;
&lt;/ipsec-ikeless&gt;
</pre><a href="#appendix-B-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="appendix-f">
<section id="appendix-C">
      <h2 id="name-xml-notification-examples">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-xml-notification-examples" class="section-name selfRef">XML Notification Examples</a>
      </h2>
<p id="appendix-C-1">In the following, several XML files are shown to
                illustrate different types of notifications defined
                in the IKE-less YANG data model, which are sent by the
                NSF to the I2NSF Controller. The notifications
                happen in the IKE-less case.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<span id="name-example-of-the-sadb-expire-"></span><div id="sadb-expire-not">
<figure id="figure-5">
        <div id="appendix-C-2.1">
<pre class="sourcecode lang-xml">
&lt;sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"&gt;
&lt;ipsec-sa-name&gt;in/trans/2001:db8:123::200/2001:db8:123::100
&lt;/ipsec-sa-name&gt;
    &lt;soft-lifetime-expire&gt;true&lt;/soft-lifetime-expire&gt;
       &lt;lifetime-current&gt;
          &lt;bytes&gt;1000000&lt;/bytes&gt;
          &lt;packets&gt;1000&lt;/packets&gt;
          &lt;time&gt;30&lt;/time&gt;
          &lt;idle&gt;60&lt;/idle&gt;
       &lt;/lifetime-current&gt;
&lt;/sadb-expire&gt;
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-of-the-sadb-expire-" class="selfRef">Example of the sadb-expire Notification</a>
        </figcaption></figure>
</div>
<span id="name-example-of-the-sadb-acquire"></span><div id="sadb-acquire-not">
<figure id="figure-6">
        <div id="appendix-C-3.1">
<pre class="sourcecode lang-xml">
&lt;sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"&gt;
    &lt;ipsec-policy-name&gt;in/trans/2001:db8:123::200/2001:db8:123::100
    &lt;/ipsec-policy-name&gt;
    &lt;traffic-selector&gt;
        &lt;local-prefix&gt;2001:db8:123::200/128&lt;/local-prefix&gt;
        &lt;remote-prefix&gt;2001:db8:123::100/128&lt;/remote-prefix&gt;
        &lt;inner-protocol&gt;any&lt;/inner-protocol&gt;
         &lt;local-ports&gt;
              &lt;start&gt;0&lt;/start&gt;
              &lt;end&gt;0&lt;/end&gt;
         &lt;/local-ports&gt;
         &lt;remote-ports&gt;
              &lt;start&gt;0&lt;/start&gt;
              &lt;end&gt;0&lt;/end&gt;
         &lt;/remote-ports&gt;
    &lt;/traffic-selector&gt;
&lt;/sadb-acquire&gt;
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-of-the-sadb-acquire" class="selfRef">Example of the sadb-acquire Notification</a>
        </figcaption></figure>
</div>
<span id="name-example-of-the-sadb-seq-ove"></span><div id="sadb-seq-overflow-not">
<figure id="figure-7">
        <div id="appendix-C-4.1">
<pre class="sourcecode lang-xml">
&lt;sadb-seq-overflow
    xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"&gt;
      &lt;ipsec-sa-name&gt;in/trans/2001:db8:123::200/2001:db8:123::100
      &lt;/ipsec-sa-name&gt;
&lt;/sadb-seq-overflow&gt;
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-of-the-sadb-seq-ove" class="selfRef">Example of the sadb-seq-overflow Notification</a>
        </figcaption></figure>
</div>
<span id="name-example-of-the-sadb-bad-spi"></span><div id="sadb-bad-spi-not">
<figure id="figure-8">
        <div id="appendix-C-5.1">
<pre class="sourcecode lang-xml">
&lt;sadb-bad-spi
         xmlns="urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"&gt;
        &lt;spi&gt;666&lt;/spi&gt;
&lt;/sadb-bad-spi&gt;
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-of-the-sadb-bad-spi" class="selfRef">Example of the sadb-bad-spi Notification</a>
        </figcaption></figure>
</div>
</section>
</div>
<div id="appendix-g">
<section id="appendix-D">
      <h2 id="name-operational-use-case-exampl">
<a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-operational-use-case-exampl" class="section-name selfRef">Operational Use Case Examples</a>
      </h2>
<div id="appendix-g1">
<section id="appendix-D.1">
        <h3 id="name-example-of-ipsec-sa-establi">
<a href="#appendix-D.1" class="section-number selfRef">D.1. </a><a href="#name-example-of-ipsec-sa-establi" class="section-name selfRef">Example of IPsec SA Establishment</a>
        </h3>
<p id="appendix-D.1-1">This appendix exemplifies the applicability of the IKE case and
            IKE-less case to traditional IPsec configurations, that is,
            host-to-host and gateway-to-gateway. The following examples assume 
      the existence of two NSFs needing to establish an
            end-to-end IPsec SA to protect their communications. Both NSFs
            could be two hosts that exchange traffic (host-to-host) or gateways
            (gateway-to-gateway), for example, within an enterprise that needs
            to protect the traffic between the networks of two branch
            offices.<a href="#appendix-D.1-1" class="pilcrow">¶</a></p>
<p id="appendix-D.1-2">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 Software as a Service (SaaS) 
     cloud services. Besides, 
     Infrastructure as a Service (IaaS)
            services providing virtualization environments are deployments that
            often rely on IPsec to provide secure channels between virtual
            instances (host-to-host) and providing VPN solutions for
            virtualized networks (gateway-to-gateway).<a href="#appendix-D.1-2" class="pilcrow">¶</a></p>
<p id="appendix-D.1-3">As can be observed in the following, the I2NSF-based
            IPsec management system (for IKE and IKE-less cases)
            exhibits various advantages:<a href="#appendix-D.1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-D.1-4">
<li id="appendix-D.1-4.1">
                    It allows creating IPsec SAs among two NSFs,
                    based only on the application
                    of general flow-based protection policies at the
                    I2NSF User. Thus, administrators can
                    manage all security associations in a
                    centralized point with an abstracted view of the
                    network.<a href="#appendix-D.1-4.1" class="pilcrow">¶</a>
</li>
          <li id="appendix-D.1-4.2">
                    Any NSF deployed in the system does not need
                    manual configuration, therefore, allowing its
                    deployment in an automated manner.<a href="#appendix-D.1-4.2" class="pilcrow">¶</a>
</li>
        </ol>
<div id="sec-example-ikecase">
<section id="appendix-D.1.1">
          <h4 id="name-ike-case-2">
<a href="#appendix-D.1.1" class="section-number selfRef">D.1.1. </a><a href="#name-ike-case-2" class="section-name selfRef">IKE Case</a>
          </h4>
<span id="name-host-to-host-gateway-to-gat"></span><div id="fig_g2gsinglecontroller1">
<figure id="figure-9">
            <div class="artwork art-text alignCenter" id="appendix-D.1.1-1.1">
<pre>
          +----------------------------------------+
          |  I2NSF User  (IPsec Management System) |
          +----------------------------------------+
                    |
           (1)    Flow-based    I2NSF Consumer-Facing
               Protection Policy       Interface
                    |
          +---------|------------------------------+
          |         |                              |
          |         |   I2NSF Controller           |
          |         V                              |
          |   +--------------+ (2)+--------------+ |
          |   |Translate into|---&gt;|   NETCONF/   | |
          |   |IPsec Policies|    |   RESTCONF   | |
          |   +--------------+    +--------------+ |
          |                          |     |       |
          |                          |     |       |
          +--------------------------|-----|-------+
                                     |     |
         I2NSF NSF-Facing Interface  |     |
                                     | (3) |
           |-------------------------+     +---|
           V                                   V
   +----------------------+         +----------------------+
   |       NSF A          |         |        NSF B         |
   | IKEv2/IPsec(SPD/PAD) |         | IKEv2/IPsec(SPD/PAD) |
   +----------------------+         +----------------------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-host-to-host-gateway-to-gat" class="selfRef">Host-to-Host/Gateway-to-Gateway for the IKE Case</a>
            </figcaption></figure>
</div>
<p id="appendix-D.1.1-2">
                     <a href="#fig_g2gsinglecontroller1" class="xref">Figure 9</a> describes the
                     application of the IKE case when a data packet needs to be
                     protected in the path between NSF A and NSF B:<a href="#appendix-D.1.1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-D.1.1-3">
     <li id="appendix-D.1.1-3.1">The I2NSF User defines a general flow-based
                          protection policy (e.g., protect data traffic between
                          NSF A and B). The I2NSF Controller looks
                          for the NSFs involved (NSF A and NSF B).<a href="#appendix-D.1.1-3.1" class="pilcrow">¶</a>
</li>
            <li id="appendix-D.1.1-3.2">The I2NSF Controller generates IKEv2
                           credentials for them and translates the policies
                           into SPD and PAD entries.<a href="#appendix-D.1.1-3.2" class="pilcrow">¶</a>
</li>
            <li id="appendix-D.1.1-3.3">The I2NSF Controller inserts an IKEv2
                           configuration that includes the SPD and PAD
                           entries in both NSF A and NSF B. If some of
                           operations with NSF A and NSF B fail, the
                           I2NSF Controller will stop the process and
                           perform a rollback operation by deleting any
                           IKEv2, SPD, and PAD configuration that had been
                           successfully installed in NSF A or B.<a href="#appendix-D.1.1-3.3" class="pilcrow">¶</a>
</li>
          </ol>
<p id="appendix-D.1.1-4"> If the previous steps are successful, the flow is
                   protected by means of the IPsec SA established with IKEv2
                   between NSF A and NSF B.<a href="#appendix-D.1.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec-example-ikeless-case">
<section id="appendix-D.1.2">
          <h4 id="name-ike-less-case-2">
<a href="#appendix-D.1.2" class="section-number selfRef">D.1.2. </a><a href="#name-ike-less-case-2" class="section-name selfRef">IKE-less Case</a>
          </h4>
<span id="name-host-to-host-gateway-to-gate"></span><div id="fig_g2gsinglecontroller2">
<figure id="figure-10">
            <div class="artwork art-text alignCenter" id="appendix-D.1.2-1.1">
<pre>
        +----------------------------------------+
        | I2NSF User  (IPsec Management System)  |
        +----------------------------------------+
                  |
       (1)   Flow-based       I2NSF Consumer-Facing
          Protection Policy      Interface
                  |
        +---------|------------------------------+
        |         |                              |
        |         |   I2NSF Controller           |
        |         V                              |
        |  +--------------+ (2) +--------------+ |
        |  |Translate into|----&gt;|   NETCONF/   | |
        |  |IPsec Policies|     |   RESTCONF   | |
        |  +--------------+     +--------------+ |
        |                         |     |        |
        +-------------------------|-----|--------+
                                  |     |
       I2NSF NSF-Facing Interface |     |
                                  | (3) |
           |----------------------+     +--|
           V                               V
  +----------------+             +----------------+
  |     NSF A      |             |     NSF B      |
  | IPsec(SPD/SAD) |             | IPsec(SPD/SAD) |
  +----------------+             +----------------+
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-host-to-host-gateway-to-gate" class="selfRef">Host-to-Host/Gateway-to-Gateway for the IKE-less Case</a>
            </figcaption></figure>
</div>
<p id="appendix-D.1.2-2">
               <a href="#fig_g2gsinglecontroller2" class="xref">Figure 10</a> describes the
               application of the IKE-less case when a data packet needs to be
               protected in the path between NSF A and NSF B:<a href="#appendix-D.1.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-D.1.2-3">
     <li id="appendix-D.1.2-3.1">The I2NSF User establishes a general flow-based
                  protection policy, and the I2NSF Controller
                  looks for the involved NSFs.<a href="#appendix-D.1.2-3.1" class="pilcrow">¶</a>
</li>
            <li id="appendix-D.1.2-3.2"> The I2NSF Controller translates the flow-based security
                  policies into IPsec SPD and SAD entries.<a href="#appendix-D.1.2-3.2" class="pilcrow">¶</a>
</li>
            <li id="appendix-D.1.2-3.3">
              <p id="appendix-D.1.2-3.3.1">The I2NSF Controller inserts these entries
                  in both NSF A and NSF B IPsec databases (i.e., SPD and
                  SAD). The following text describes how this
                  would happen:<a href="#appendix-D.1.2-3.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-D.1.2-3.3.2.1">The I2NSF Controller chooses two random
                       values as SPIs, for example, SPIa1 for the
                       inbound IPsec SA in NSF A and SPIb1 for
                       the inbound IPsec SA in NSF B. The value of
                       the SPIa1 <span class="bcp14">MUST NOT</span> be the same as any inbound
                       SPI in A. In the same way, the value of the
                       SPIb1 <span class="bcp14">MUST NOT</span> be the same as any inbound SPI
                       in B. Moreover, the SPIa1 <span class="bcp14">MUST</span> be used in B
                       for the outbound IPsec SA to A, while SPIb1
                       <span class="bcp14">MUST</span> be used in A for the outbound IPsec SA
                       to B.
                       It also generates fresh cryptographic
                       material for the new inbound/outbound IPsec
                       SAs and their parameters.<a href="#appendix-D.1.2-3.3.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-D.1.2-3.3.2.2"> After that, the I2NSF Controller simultaneously sends
                       the new inbound IPsec SA with SPIa1 and
                       new outbound IPsec SA with SPIb1 to NSF A and the new
                       inbound IPsec SA with SPIb1 and new outbound
                       IPsec SA with SPIa1 to B, together with the
                       corresponding IPsec policies.<a href="#appendix-D.1.2-3.3.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="appendix-D.1.2-3.3.2.3">Once the I2NSF Controller receives confirmation from
                       NSF A and NSF B, it knows that the IPsec SAs are
                       correctly installed and ready.<a href="#appendix-D.1.2-3.3.2.3" class="pilcrow">¶</a>
</li>
              </ul>
<p id="appendix-D.1.2-3.3.3"> Another alternative to this operation is
                     the I2NSF Controller first sends the IPsec
                     policies and new inbound IPsec SAs to A and B.
                     Once it obtains a successful confirmation of
                     these operations from NSF A and NSF B, it
                     proceeds with installing the new outbound
                     IPsec SAs. Even though this procedure may increase the
                     latency to complete the process, no traffic is sent
                     over the network until the IPsec SAs are
                     completely operative. In any case, other
                     alternatives <span class="bcp14">MAY</span> be possible to implement step 3.<a href="#appendix-D.1.2-3.3.3" class="pilcrow">¶</a></p>
</li>
            <li id="appendix-D.1.2-3.4">If some of the operations described above fail
               (e.g., NSF A reports an error when the
               I2NSF Controller is trying to install the SPD
               entry, the new inbound or outbound IPsec SAs),
               the I2NSF Controller <span class="bcp14">MUST</span> perform rollback
               operations by deleting any new inbound or
               outbound IPsec SA and SPD entry that had been
               successfully installed in any of the NSFs 
               (e.g., NSF B) and stop the process. Note that the 
               I2NSF Controller <span class="bcp14">MAY</span> retry several
               times before giving up.<a href="#appendix-D.1.2-3.4" class="pilcrow">¶</a>
</li>
            <li id="appendix-D.1.2-3.5"> Otherwise, if the steps 1 to 3 are successful, the flow
                between NSF A and NSF B is protected by means of the IPsec SAs 
                established by the I2NSF Controller. It is worth mentioning that
                the I2NSF Controller associates a lifetime to the new IPsec SAs.
                When this lifetime expires, the NSF will send a sadb-expire
                notification to the I2NSF Controller in order to start the
                rekeying process.<a href="#appendix-D.1.2-3.5" class="pilcrow">¶</a>
</li>
          </ol>
<p id="appendix-D.1.2-4">Instead of installing IPsec policies (in the SPD) and IPsec
      SAs (in the SAD) in step 3 (proactive mode), it is also
      possible that the I2NSF Controller only installs the SPD
      entries in step 3 (reactive mode). In such a case, when a
      data packet requires to be protected with IPsec, the NSF
      that first saw the data packet will send a sadb-acquire
      notification that informs the I2NSF Controller that needs
      SAD entries with the IPsec SAs to process the data
      packet. Again, if some of the operations installing 
      the new inbound/outbound IPsec SAs fail, the I2NSF Controller stops the
      process and performs a rollback operation by deleting any new
      inbound/outbound SAs that had been successfully installed.<a href="#appendix-D.1.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="appendix-g2">
<section id="appendix-D.2">
        <h3 id="name-example-of-the-rekeying-pro">
<a href="#appendix-D.2" class="section-number selfRef">D.2. </a><a href="#name-example-of-the-rekeying-pro" class="section-name selfRef">Example of the Rekeying Process in IKE-less Case</a>
        </h3>
<p id="appendix-D.2-1">To explain an example of the rekeying process between two
        IPsec NSFs, A and B, assume that SPIa1
        identifies the inbound IPsec SA in A and SPIb1 identifies
        the inbound IPsec SA in B. The rekeying process
         will take the following steps:<a href="#appendix-D.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-D.2-2">
   <li id="appendix-D.2-2.1">The I2NSF Controller chooses two
                            random values as SPI for the new inbound
                            IPsec SAs, for example, SPIa2 for the
                            inbound IPsec SA in A and SPIb2 for the
                            inbound IPsec SA in B. The value of the
                            SPIa1 <span class="bcp14">MUST NOT</span> be the same as any
                            inbound SPI in A. In the same way, the
                            value of the SPIb1 <span class="bcp14">MUST NOT</span> be the same
                            as any inbound SPI in B. Then,
                            the I2NSF Controller creates an inbound IPsec SA
                            with SPIa2 in A and another inbound IPsec SA in B
                            with SPIb2. It can send this information
                            simultaneously to A and B.<a href="#appendix-D.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="appendix-D.2-2.2"> Once the I2NSF Controller receives
                            confirmation from A and B, the controller knows that
                            the inbound IPsec SAs are correctly installed. Then,
                            it proceeds to send, in parallel to A and B, the
                            outbound IPsec SAs: the outbound IPsec SA
                            to A with SPIb2 and the outbound IPsec SA to B with
                            SPIa2. At this point, the new IPsec SAs are
                            ready.<a href="#appendix-D.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="appendix-D.2-2.3"> Once the I2NSF Controller receives
                            confirmation from A and B that the outbound IPsec
                            SAs have been installed, the I2NSF Controller, in
                            parallel, deletes the old IPsec SAs from A (inbound
                            SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
                            inbound SPIb1).<a href="#appendix-D.2-2.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="appendix-D.2-3">If some of the operations in step 1 fail (e.g.,
                    NSF A reports an error when the I2NSF Controller is
                    trying to install a new inbound IPsec SA), the
                    I2NSF Controller <span class="bcp14">MUST</span> perform rollback operations by
                    removing any new inbound SA that had been successfully
                    installed during step 1.<a href="#appendix-D.2-3" class="pilcrow">¶</a></p>
<p id="appendix-D.2-4">If step 1 is successful but some of the operations in
                    step 2 fail (e.g., NSF A reports an error when the
                    I2NSF Controller is trying to install the new
                    outbound IPsec SA), the I2NSF Controller <span class="bcp14">MUST</span> perform
                    a rollback operation by deleting any new outbound SA
                    that had been successfully installed during step 2 and
                    by deleting the inbound SAs created in step 1,
                    in that order.<a href="#appendix-D.2-4" class="pilcrow">¶</a></p>
<p id="appendix-D.2-5">If the steps 1 and 2 are successful but the step 3
                    fails, the I2NSF Controller will avoid any rollback of
                    the operations carried out in steps 1 and 2, since
                    new and valid IPsec SAs were created and are functional.
                    The I2NSF Controller <span class="bcp14">MAY</span> reattempt to remove the old
                    inbound and outbound IPsec SAs in NSF A and NSF B several times
                    until it receives a success or it gives up. In the last
                    case, the old IPsec SAs will be removed when their
                    corresponding hard lifetime is reached.<a href="#appendix-D.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="appendix-g3">
<section id="appendix-D.3">
        <h3 id="name-example-of-managing-nsf-sta">
<a href="#appendix-D.3" class="section-number selfRef">D.3. </a><a href="#name-example-of-managing-nsf-sta" class="section-name selfRef">Example of Managing NSF State Loss in the IKE-less Case</a>
        </h3>
<p id="appendix-D.3-1"> In the IKE-less case, if the I2NSF Controller detects
                    that an NSF has lost the IPsec state, it could follow the
                    next steps:<a href="#appendix-D.3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-D.3-2">
   <li id="appendix-D.3-2.1"> The I2NSF Controller <span class="bcp14">SHOULD</span> delete the old
                            IPsec SAs on the non-failed nodes, established with
                            the failed node. This prevents the non-failed nodes
                            from leaking plaintext.<a href="#appendix-D.3-2.1" class="pilcrow">¶</a>
</li>
          <li id="appendix-D.3-2.2">If the affected node restarts, the I2NSF
                            Controller configures the new inbound IPsec SAs
                            between the affected node and all the nodes it was
                            talking to.<a href="#appendix-D.3-2.2" class="pilcrow">¶</a>
</li>
          <li id="appendix-D.3-2.3"> After these inbound IPsec SAs have been
                            established, the I2NSF Controller configures the
                            outbound IPsec SAs in parallel.<a href="#appendix-D.3-2.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="appendix-D.3-3">Steps 2 and 3 can be performed at the same time at
                     the cost of a potential packet loss. If this is not
                     critical, then it is an optimization since the number of
                     exchanges between the I2NSF Controller and NSFs is lower.<a href="#appendix-D.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ack">
<section id="appendix-E">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-E-1">
         Authors want to thank <span class="contact-name">Paul Wouters</span>, <span class="contact-name">Valery          Smyslov</span>, <span class="contact-name">Sowmini Varadhan</span>, <span class="contact-name">David Carrel</span>,
  <span class="contact-name">Yoav Nir</span>, <span class="contact-name">Tero Kivinen</span>,
         <span class="contact-name">Martin Bjorklund</span>, <span class="contact-name">Graham Bartlett</span>, 
  <span class="contact-name">Sandeep Kampati</span>, <span class="contact-name">Linda          Dunbar</span>, <span class="contact-name">Mohit Sethi</span>, <span class="contact-name">Martin Bjorklund</span>,
  <span class="contact-name">Tom Petch</span>, <span class="contact-name">Christian          Hopps</span>, <span class="contact-name">Rob Wilton</span>, <span class="contact-name">Carlos J. Bernardos</span>,
  <span class="contact-name">Alejandro Perez-Mendez</span>, <span class="contact-name">Alejandro   Abad-Carrascosa</span>, <span class="contact-name">Ignacio          Martinez</span>, <span class="contact-name">Ruben Ricart</span>, and all IESG members
         that have reviewed this document for their
         valuable comments.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-F">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Rafa Marin-Lopez</span></div>
<div dir="auto" class="left"><span class="org">University of Murcia</span></div>
<div dir="auto" class="left"><span class="extended-address">Faculty of Computer Science</span></div>
<div dir="auto" class="left"><span class="street-address">Campus de Espinardo S/N</span></div>
<div dir="auto" class="left">
<span class="postal-code">30100</span>  <span class="region">Murcia</span>
</div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%20868%2088%2085%2001" class="tel">+34 868 88 85 01</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:rafa@um.es" class="email">rafa@um.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Gabriel Lopez-Millan</span></div>
<div dir="auto" class="left"><span class="org">University of Murcia</span></div>
<div dir="auto" class="left"><span class="extended-address">Faculty of Computer Science</span></div>
<div dir="auto" class="left"><span class="street-address">Campus de Espinardo S/N</span></div>
<div dir="auto" class="left">
<span class="postal-code">30100</span>  <span class="region">Murcia</span>
</div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%20868%2088%2085%2004" class="tel">+34 868 88 85 04</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:gabilm@um.es" class="email">gabilm@um.es</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Fernando Pereniguez-Garcia</span></div>
<div dir="auto" class="left"><span class="org">University Defense Center</span></div>
<div dir="auto" class="left"><span class="extended-address">Spanish Air Force Academy</span></div>
<div dir="auto" class="left"><span class="street-address">MDE-UPCT</span></div>
<div dir="auto" class="left">
<span class="postal-code">30720</span> <span class="locality">San Javier</span> <span class="region">Murcia</span>
</div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+34%20968%2018%2099%2046" class="tel">+34 968 18 99 46</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:fernando.pereniguez@cud.upct.es" class="email">fernando.pereniguez@cud.upct.es</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>