< draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt >
I2NSF R. Marin-Lopez I2NSF R. Marin-Lopez
Internet-Draft G. Lopez-Millan Internet-Draft G. Lopez-Millan
Intended status: Standards Track University of Murcia Intended status: Standards Track University of Murcia
Expires: January 29, 2020 F. Pereniguez-Garcia Expires: February 6, 2020 F. Pereniguez-Garcia
University Defense Center University Defense Center
July 28, 2019 August 5, 2019
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-06 draft-ietf-i2nsf-sdn-ipsec-flow-protection-07
Abstract Abstract
This document describes how providing IPsec-based flow protection by This document describes how providing IPsec-based flow protection by
means of a Software-Defined Network (SDN) controller (aka. Security means of a Software-Defined Network (SDN) controller (aka. Security
Controller) and establishes the requirements to support this service. Controller) and establishes the requirements to support this service.
It considers two main well-known scenarios in IPsec: (i) gateway-to- It considers two main well-known scenarios in IPsec: (i) gateway-to-
gateway and (ii) host-to-host. The SDN-based service described in gateway and (ii) host-to-host. The SDN-based service described in
this document allows the distribution and monitoring of IPsec this document allows the distribution and monitoring of IPsec
information from a Security Controller to one or several flow-based information from a Security Controller to one or several flow-based
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2020. This Internet-Draft will expire on February 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Appendix A: Common YANG model for IKE and IKE-less Appendix A. Appendix A: Common YANG model for IKE and IKE-less
cases . . . . . . . . . . . . . . . . . . . . . . . 35 cases . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48
Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67
Appendix D. Example of IKE case, tunnel mode (gateway-to- Appendix D. Example of IKE case, tunnel mode (gateway-to-
gateway) with X.509 certificate authentication. . . 77 gateway) with X.509 certificate authentication. . . 77
Appendix E. Example of IKE-less case, transport mode (host-to- Appendix E. Example of IKE-less case, transport mode (host-to-
host). . . . . . . . . . . . . . . . . . . . . . . . 80 host). . . . . . . . . . . . . . . . . . . . . . . . 81
Appendix F. Examples of notifications. . . . . . . . . . . . . . 84 Appendix F. Examples of notifications. . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
Software-Defined Networking (SDN) is an architecture that enables Software-Defined Networking (SDN) is an architecture that enables
users to directly program, orchestrate, control and manage network users to directly program, orchestrate, control and manage network
resources through software. The SDN paradigm relocates the control resources through software. The SDN paradigm relocates the control
of network resources to a dedicated network element, namely SDN of network resources to a dedicated network element, namely SDN
Controller. The SDN controller (or Security Controller in the Controller. The SDN controller (or Security Controller in the
context of this document) manages and configures the distributed context of this document) manages and configures the distributed
skipping to change at page 4, line 51 skipping to change at page 4, line 51
Finally, this work pays attention to the challenge "Lack of Mechanism Finally, this work pays attention to the challenge "Lack of Mechanism
for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the
particular case of the establishment and management of IPsec SAs. In particular case of the establishment and management of IPsec SAs. In
fact,this I-D could be considered as a proper use case for this fact,this I-D could be considered as a proper use case for this
particular challenge in [RFC8192]. particular challenge in [RFC8192].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. When these words appear in lower case, they have
When these words appear in lower case, they have their natural their natural language meaning.
language meaning.
3. Terminology 3. Terminology
This document uses the terminology described in [RFC7149], [RFC4301], This document uses the terminology described in [RFC7149], [RFC4301],
[ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow],
[ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In
addition, the following terms are defined below: addition, the following terms are defined below:
o Software-Defined Networking. A set of techniques enabling to o Software-Defined Networking. A set of techniques enabling to
directly program, orchestrate, control, and manage network directly program, orchestrate, control, and manage network
skipping to change at page 11, line 22 skipping to change at page 11, line 22
Security Controller receives a sadb-expire notification or it decides Security Controller receives a sadb-expire notification or it decides
so, based on lifetime state data obtained from the NSF. so, based on lifetime state data obtained from the NSF.
To explain the rekeying process between two IPsec NSFs A and B, let To explain the rekeying process between two IPsec NSFs A and B, let
assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the
inbound IPsec SA in B. The rekeying process will take the following inbound IPsec SA in B. The rekeying process will take the following
steps: steps:
1. The Security Controller chooses two random values as SPI for the 1. The Security Controller chooses two random values as SPI for the
new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B. new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B.
These numbers MUST not be in conflict with any IPsec SA in A or These numbers MUST NOT be in conflict with any IPsec SA in A or
B. Then, the Security Controller creates an inbound IPsec SA B. Then, the Security Controller creates an inbound IPsec SA
with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It
can send this information simultaneously to A and B. can send this information simultaneously to A and B.
2. Once the Security Controller receives confirmation from A and B, 2. Once the Security Controller receives confirmation from A and B,
the controller knows that the inbound IPsec A are correctly the controller knows that the inbound IPsec A are correctly
installed. Then it proceeds to send in parallel to A and B, the installed. Then it proceeds to send in parallel to A and B, the
outbound IPsec SAs: it sends the outbound IPsec SA to A with outbound IPsec SAs: it sends the outbound IPsec SA to A with
SPIb2 and the outbound IPsec SA to B with SPIa2. At this point SPIb2 and the outbound IPsec SA to B with SPIa2. At this point
the new IPsec SAs are ready. the new IPsec SAs are ready.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
because these NSFs inform the Security Controller. Based on this because these NSFs inform the Security Controller. Based on this
information, the Security Controller can guess if there is a NAT information, the Security Controller can guess if there is a NAT
configured between two hosts, and apply the required policies to both configured between two hosts, and apply the required policies to both
NSFs besides activating the usage of UDP or TCP/TLS encapsulation of NSFs besides activating the usage of UDP or TCP/TLS encapsulation of
ESP packets ([RFC3948], [RFC8229]). ESP packets ([RFC3948], [RFC8229]).
For example, the Security Controller could directly request the NSF For example, the Security Controller could directly request the NSF
for specific data such as networking configuration, NAT support, etc. for specific data such as networking configuration, NAT support, etc.
Protocols such as NETCONF or SNMP can be used here. For example, RFC Protocols such as NETCONF or SNMP can be used here. For example, RFC
7317 [RFC7317] provides a YANG data model for system management or 7317 [RFC7317] provides a YANG data model for system management or
[I-D.ietf-opsawg-nat-yang] a data model for NAT management. The [RFC8512] a data model for NAT management. The Security Controller
Security Controller can use this NETCONF module with a NSF to collect can use this NETCONF module with a NSF to collect NAT information or
NAT information or even configure a NAT network. In any case, if even configure a NAT network. In any case, if this NETCONF module is
this NETCONF module is not available in the NSF and the Security not available in the NSF and the Security Controller does not have a
Controller does not have a mechanism to know whether a host is behind mechanism to know whether a host is behind a NAT or not, then the IKE
a NAT or not, then the IKE case should be the right choice and not case should be the right choice and not the IKE-less case.
the IKE-less case.
5.3.4. NSF Discovery 5.3.4. NSF Discovery
The assumption in this document is that, for both cases, before a NSF The assumption in this document is that, for both cases, before a NSF
can operate in this system, it MUST be registered in the Security can operate in this system, it MUST be registered in the Security
Controller. In this way, when the NSF comes to live and establishes Controller. In this way, when the NSF comes to live and establishes
a connection to the Security Controller, it knows that the NSF is a connection to the Security Controller, it knows that the NSF is
valid for joining the system. valid for joining the system.
Either during this registration process or when the NSF connects with Either during this registration process or when the NSF connects with
skipping to change at page 14, line 23 skipping to change at page 14, line 22
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296], and observing some open source
implementations, such as Strongswan [strongswan] or Libreswan implementations, such as Strongswan [strongswan] or Libreswan
[libreswan]. [libreswan].
The definition of the PAD model has been extracted from the The definition of the PAD model has been extracted from the
specification in section 4.4.3 in [RFC4301] (NOTE: We have observed specification in section 4.4.3 in [RFC4301] (NOTE: We have observed
that many implementations integrate PAD configuration as part of the that many implementations integrate PAD configuration as part of the
IKEv2 configuration). IKEv2 configuration).
module: ietf-ipsec-ike module: ietf-ipsec-ike
+--rw ipsec-ike +--rw ipsec-ike
+--rw pad +--rw pad
| +--rw pad-entry* [name] | +--rw pad-entry* [name]
| +--rw name string | +--rw name string
| +--rw (identity) | +--rw (identity)
| | +--:(ipv4-address) | | +--:(ipv4-address)
| | | +--rw ipv4-address? inet:ipv4-address | | | +--rw ipv4-address? inet:ipv4-address
| | +--:(ipv6-address) | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address | | | +--rw ipv6-address? inet:ipv6-address
| | +--:(fqdn-string) | | +--:(fqdn-string)
| | | +--rw fqdn-string? inet:domain-name | | | +--rw fqdn-string? inet:domain-name
skipping to change at page 14, line 47 skipping to change at page 14, line 46
| | +--:(dnx509) | | +--:(dnx509)
| | | +--rw dnx509? string | | | +--rw dnx509? string
| | +--:(gnx509) | | +--:(gnx509)
| | | +--rw gnx509? string | | | +--rw gnx509? string
| | +--:(id-key) | | +--:(id-key)
| | | +--rw id-key? string | | | +--rw id-key? string
| | +--:(id-null) | | +--:(id-null)
| | +--rw id-null? empty | | +--rw id-null? empty
| +--rw auth-protocol? auth-protocol-type | +--rw auth-protocol? auth-protocol-type
| +--rw peer-authentication | +--rw peer-authentication
| +--rw auth-method? auth-method-type | +--rw auth-method? auth-method-type
| +--rw eap-method | +--rw eap-method
| | +--rw eap-type uint8 | | +--rw eap-type uint8
| +--rw pre-shared | +--rw pre-shared
| | +--rw secret? yang:hex-string | | +--rw secret? yang:hex-string
| +--rw digital-signature | +--rw digital-signature
| +--rw ds-algorithm? uint8 | +--rw ds-algorithm? uint8
| +--rw (public-key) | +--rw (public-key)
| | +--:(raw-public-key) | | +--:(raw-public-key)
| | | +--rw raw-public-key? binary | | | +--rw raw-public-key? binary
| | +--:(cert-data) | | +--:(cert-data)
| | +--rw cert-data? ct:x509 | | +--rw cert-data? ct:x509
| +--rw private-key? binary | +--rw private-key? binary
| +--rw ca-data* ct:x509 | +--rw ca-data* ct:x509
| +--rw crl-data? ct:crl | +--rw crl-data? ct:crl
| +--rw crl-uri? inet:uri | +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri | +--rw oscp-uri? inet:uri
skipping to change at page 15, line 45 skipping to change at page 15, line 44
| | +--rw local-pad-entry-name? string | | +--rw local-pad-entry-name? string
| +--rw remote | +--rw remote
| | +--rw remote-pad-entry-name? string | | +--rw remote-pad-entry-name? string
| +--rw encapsulation-type | +--rw encapsulation-type
| | +--rw espencap? esp-encap | | +--rw espencap? esp-encap
| | +--rw sport? inet:port-number | | +--rw sport? inet:port-number
| | +--rw dport? inet:port-number | | +--rw dport? inet:port-number
| | +--rw oaddr* inet:ip-address | | +--rw oaddr* inet:ip-address
| +--rw spd | +--rw spd
| | +--rw spd-entry* [name] | | +--rw spd-entry* [name]
| | +--rw name string | | +--rw name string
| | +--rw ipsec-policy-config | | +--rw ipsec-policy-config
| | +--rw anti-replay-window? uint64 | | +--rw anti-replay-window? uint64
| | +--rw traffic-selector | | +--rw traffic-selector
| | | +--rw local-subnet inet:ip-prefix | | | +--rw local-subnet inet:ip-prefix
| | | +--rw remote-subnet inet:ip-prefix | | | +--rw remote-subnet inet:ip-prefix
| | | +--rw inner-protocol? ipsec-inner-protocol | | | +--rw inner-protocol? ipsec-inner-protocol
| | | +--rw local-ports* [start end] | | | +--rw local-ports* [start end]
| | | | +--rw start inet:port-number | | | | +--rw start inet:port-number
| | | | +--rw end inet:port-number | | | | +--rw end inet:port-number
| | | +--rw remote-ports* [start end] | | | +--rw remote-ports* [start end]
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw processing-info | | +--rw processing-info
| | | +--rw action? ipsec-spd-action | | | +--rw action? ipsec-spd-action
| | | +--rw ipsec-sa-cfg | | | +--rw ipsec-sa-cfg
| | | +--rw pfp-flag? boolean | | | +--rw pfp-flag? boolean
| | | +--rw ext-seq-num? boolean | | | +--rw ext-seq-num? boolean
| | | +--rw seq-overflow? boolean | | | +--rw seq-overflow? boolean
| | | +--rw stateful-frag-check? boolean | | | +--rw stateful-frag-check? boolean
| | | +--rw mode? ipsec-mode | | | +--rw mode? ipsec-mode
| | | +--rw protocol-parameters? ipsec-protocol-parameters | | | +--rw protocol-parameters? ipsec-protocol-parameters
| | | +--rw esp-algorithms | | | +--rw esp-algorithms
| | | | +--rw integrity* integrity-algorithm-type | | | | +--rw integrity* integrity-algorithm-type
| | | | +--rw encryption* encryption-algorithm-type | | | | +--rw encryption* encryption-algorithm-type
| | | | +--rw tfc-pad? boolean | | | | +--rw tfc-pad? boolean
| | | +--rw tunnel | | | +--rw tunnel
| | | +--rw local inet:ip-address | | | +--rw local inet:ip-address
| | | +--rw remote inet:ip-address | | | +--rw remote inet:ip-address
| | | +--rw df-bit? enumeration | | | +--rw df-bit? enumeration
| | | +--rw bypass-dscp? boolean | | | +--rw bypass-dscp? boolean
| | | +--rw dscp-mapping? yang:hex-string | | | +--rw dscp-mapping? yang:hex-string
| | | +--rw ecn? boolean | | | +--rw ecn? boolean
| | +--rw spd-mark | | +--rw spd-mark
| | +--rw mark? uint32 | | +--rw mark? uint32
| | +--rw mask? yang:hex-string | | +--rw mask? yang:hex-string
| +--rw child-sa-info | +--rw child-sa-info
| | +--rw pfs-groups* pfs-group | | +--rw pfs-groups* pfs-group
| | +--rw child-sa-lifetime-soft | | +--rw child-sa-lifetime-soft
| | | +--rw time? uint32 | | | +--rw time? uint32
| | | +--rw bytes? uint32 | | | +--rw bytes? uint32
| | | +--rw packets? uint32 | | | +--rw packets? uint32
| | | +--rw idle? uint32 | | | +--rw idle? uint32
| | | +--rw action? ic:lifetime-action | | | +--rw action? ic:lifetime-action
| | +--rw child-sa-lifetime-hard | | +--rw child-sa-lifetime-hard
| | +--rw time? uint32 | | +--rw time? uint32
skipping to change at page 17, line 39 skipping to change at page 17, line 38
The definition of the SAD model has been extracted from the The definition of the SAD model has been extracted from the
specification in section 4.4.2 in [RFC4301]. Note that this model specification in section 4.4.2 in [RFC4301]. Note that this model
not only allows to associate an IPsec SA with its corresponding not only allows to associate an IPsec SA with its corresponding
policy through the specific traffic selector but also an identifier policy through the specific traffic selector but also an identifier
(reqid). (reqid).
The notifications model has been defined using as reference the The notifications model has been defined using as reference the
PF_KEYv2 standard in [RFC2367]. PF_KEYv2 standard in [RFC2367].
module: ietf-ipsec-ikeless module: ietf-ipsec-ikeless
+--rw ipsec-ikeless +--rw ipsec-ikeless
+--rw spd +--rw spd
| +--rw spd-entry* [name] | +--rw spd-entry* [name]
| +--rw name string | +--rw name string
| +--rw direction? ic:ipsec-traffic-direction | +--rw direction? ic:ipsec-traffic-direction
| +--rw reqid? uint64 | +--rw reqid? uint64
| +--rw ipsec-policy-config | +--rw ipsec-policy-config
| +--rw anti-replay-window? uint64 | +--rw anti-replay-window? uint64
| +--rw traffic-selector | +--rw traffic-selector
| | +--rw local-subnet inet:ip-prefix | | +--rw local-subnet inet:ip-prefix
| | +--rw remote-subnet inet:ip-prefix | | +--rw remote-subnet inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end] | | +--rw local-ports* [start end]
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw remote-ports* [start end] | | +--rw remote-ports* [start end]
| | +--rw start inet:port-number | | +--rw start inet:port-number
| | +--rw end inet:port-number | | +--rw end inet:port-number
| +--rw processing-info | +--rw processing-info
| | +--rw action? ipsec-spd-action | | +--rw action? ipsec-spd-action
| | +--rw ipsec-sa-cfg | | +--rw ipsec-sa-cfg
| | +--rw pfp-flag? boolean | | +--rw pfp-flag? boolean
| | +--rw ext-seq-num? boolean | | +--rw ext-seq-num? boolean
| | +--rw seq-overflow? boolean | | +--rw seq-overflow? boolean
| | +--rw stateful-frag-check? boolean | | +--rw stateful-frag-check? boolean
| | +--rw mode? ipsec-mode | | +--rw mode? ipsec-mode
| | +--rw protocol-parameters? | | +--rw protocol-parameters?
| | +--rw esp-algorithms | | +--rw esp-algorithms
| | | +--rw integrity* integrity-algorithm-type | | | +--rw integrity* integrity-algorithm-type
| | | +--rw encryption* encryption-algorithm-type | | | +--rw encryption* encryption-algorithm-type
| | | +--rw tfc-pad? boolean | | | +--rw tfc-pad? boolean
| | +--rw tunnel | | +--rw tunnel
| | +--rw local inet:ip-address | | +--rw local inet:ip-address
| | +--rw remote inet:ip-address | | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration | | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean | | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string | | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean | | +--rw ecn? boolean
| +--rw spd-mark | +--rw spd-mark
| +--rw mark? uint32 | +--rw mark? uint32
| +--rw mask? yang:hex-string | +--rw mask? yang:hex-string
+--rw sad +--rw sad
+--rw sad-entry* [name] +--rw sad-entry* [name]
+--rw name string +--rw name string
+--rw reqid? uint64 +--rw reqid? uint64
+--rw ipsec-sa-config +--rw ipsec-sa-config
| +--rw spi uint32 | +--rw spi uint32
| +--rw ext-seq-num? boolean | +--rw ext-seq-num? boolean
| +--rw seq-number-counter? uint64 | +--rw seq-number-counter? uint64
| +--rw seq-overflow? boolean | +--rw seq-overflow? boolean
| +--rw anti-replay-window? uint32 | +--rw anti-replay-window? uint32
| +--rw traffic-selector | +--rw traffic-selector
| | +--rw local-subnet inet:ip-prefix | | +--rw local-subnet inet:ip-prefix
| | +--rw remote-subnet inet:ip-prefix | | +--rw remote-subnet inet:ip-prefix
| | +--rw inner-protocol? ipsec-inner-protocol | | +--rw inner-protocol? ipsec-inner-protocol
| | +--rw local-ports* [start end] | | +--rw local-ports* [start end]
| | | +--rw start inet:port-number | | | +--rw start inet:port-number
| | | +--rw end inet:port-number | | | +--rw end inet:port-number
| | +--rw remote-ports* [start end] | | +--rw remote-ports* [start end]
| | +--rw start inet:port-number | | +--rw start inet:port-number
| | +--rw end inet:port-number | | +--rw end inet:port-number
| +--rw protocol-parameters? ic:ipsec-protocol-parameters | +--rw protocol-parameters? ic:ipsec-protocol-parameters
| +--rw mode? ic:ipsec-mode | +--rw mode? ic:ipsec-mode
| +--rw esp-sa | +--rw esp-sa
| | +--rw encryption | | +--rw encryption
| | | +--rw encryption-algorithm? ic:encryption-algorithm-type | | | +--rw encryption-algorithm? ic:encryption-algorithm-type
| | | +--rw key? yang:hex-string | | | +--rw key? yang:hex-string
| | | +--rw iv? yang:hex-string | | | +--rw iv? yang:hex-string
| | +--rw integrity | | +--rw integrity
| | +--rw integrity-algorithm? ic:integrity-algorithm-type | | +--rw integrity-algorithm? ic:integrity-algorithm-type
| | +--rw key? yang:hex-string | | +--rw key? yang:hex-string
| +--rw sa-lifetime-hard | +--rw sa-lifetime-hard
| | +--rw time? uint32 | | +--rw time? uint32
| | +--rw bytes? uint32 | | +--rw bytes? uint32
| | +--rw packets? uint32 | | +--rw packets? uint32
| | +--rw idle? uint32 | | +--rw idle? uint32
| +--rw sa-lifetime-soft | +--rw sa-lifetime-soft
| | +--rw time? uint32 | | +--rw time? uint32
| | +--rw bytes? uint32 | | +--rw bytes? uint32
| | +--rw packets? uint32 | | +--rw packets? uint32
| | +--rw idle? uint32 | | +--rw idle? uint32
| | +--rw action? ic:lifetime-action | | +--rw action? ic:lifetime-action
| +--rw tunnel | +--rw tunnel
| | +--rw local inet:ip-address | | +--rw local inet:ip-address
| | +--rw remote inet:ip-address | | +--rw remote inet:ip-address
| | +--rw df-bit? enumeration | | +--rw df-bit? enumeration
| | +--rw bypass-dscp? boolean | | +--rw bypass-dscp? boolean
| | +--rw dscp-mapping? yang:hex-string | | +--rw dscp-mapping? yang:hex-string
| | +--rw ecn? boolean | | +--rw ecn? boolean
| +--rw encapsulation-type | +--rw encapsulation-type
| +--rw espencap? esp-encap | +--rw espencap? esp-encap
| +--rw sport? inet:port-number | +--rw sport? inet:port-number
| +--rw dport? inet:port-number | +--rw dport? inet:port-number
| +--rw oaddr* inet:ip-address | +--rw oaddr* inet:ip-address
+--ro ipsec-sa-state +--ro ipsec-sa-state
+--ro sa-lifetime-current +--ro sa-lifetime-current
| +--ro time? uint32 | +--ro time? uint32
| +--ro bytes? uint32 | +--ro bytes? uint32
| +--ro packets? uint32 | +--ro packets? uint32
| +--ro idle? uint32 | +--ro idle? uint32
+--ro replay-stats +--ro replay-stats
+--ro replay-window? uint64 +--ro replay-window? uint64
+--ro packet-dropped? uint64 +--ro packet-dropped? uint64
+--ro failed? uint32 +--ro failed? uint32
+--ro seq-number-counter? uint64 +--ro seq-number-counter? uint64
notifications: notifications:
+---n sadb-acquire
| +--ro ipsec-policy-name string +---n sadb-acquire
| +--ro traffic-selector | +--ro ipsec-policy-name string
| +--ro local-subnet inet:ip-prefix | +--ro traffic-selector
| +--ro remote-subnet inet:ip-prefix | +--ro local-subnet inet:ip-prefix
| +--ro inner-protocol? ipsec-inner-protocol | +--ro remote-subnet inet:ip-prefix
| +--ro local-ports* [start end] | +--ro inner-protocol? ipsec-inner-protocol
| | +--ro start inet:port-number | +--ro local-ports* [start end]
| | +--ro end inet:port-number | | +--ro start inet:port-number
| +--ro remote-ports* [start end] | | +--ro end inet:port-number
| +--ro start inet:port-number | +--ro remote-ports* [start end]
| +--ro end inet:port-number | +--ro start inet:port-number
+---n sadb-expire | +--ro end inet:port-number
| +--ro ipsec-sa-name string +---n sadb-expire
| +--ro soft-lifetime-expire? boolean | +--ro ipsec-sa-name string
| +--ro lifetime-current | +--ro soft-lifetime-expire? boolean
| +--ro time? uint32 | +--ro lifetime-current
| +--ro bytes? uint32 | +--ro time? uint32
| +--ro packets? uint32 | +--ro bytes? uint32
| +--ro idle? uint32 | +--ro packets? uint32
+---n sadb-seq-overflow | +--ro idle? uint32
| +--ro ipsec-sa-name string +---n sadb-seq-overflow
+---n sadb-bad-spi | +--ro ipsec-sa-name string
+--ro spi uint32 +---n sadb-bad-spi
+--ro spi uint32
Appendix E shows an example of IKE-less case configuration for a NSF, Appendix E shows an example of IKE-less case configuration for a NSF,
in transport mode (host-to-host), with NSFs authentication based on in transport mode (host-to-host), with NSFs authentication based on
shared secrets. For the IKE-less case, Appendix F shows examples of shared secrets. For the IKE-less case, Appendix F shows examples of
IPsec SA expire, acquire, sequence number overflow and bad SPI IPsec SA expire, acquire, sequence number overflow and bad SPI
notifications. notifications.
7. Use cases examples 7. Use cases examples
This section explains how different traditional configurations, that This section explains how different traditional configurations, that
skipping to change at page 23, line 7 skipping to change at page 23, line 7
2. The Security Controller translates the flow-based security 2. The Security Controller translates the flow-based security
policies into IPsec SPD and SAD entries. policies into IPsec SPD and SAD entries.
3. The Security Controller inserts these entries in both NSF A and 3. The Security Controller inserts these entries in both NSF A and
NSF B IPsec databases (SPD and SAD). The following text NSF B IPsec databases (SPD and SAD). The following text
describes how this happens between two NSFs A and B: describes how this happens between two NSFs A and B:
* The Security Controller chooses two random values as SPIs: for * The Security Controller chooses two random values as SPIs: for
example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers
MUST not be in conflict with any IPsec SA in NSF A or NSF B. MUST NOT be in conflict with any IPsec SA in NSF A or NSF B.
It also generates fresh cryptographic material for the new It also generates fresh cryptographic material for the new
inbound/outbound IPsec SAs and their parameters and send inbound/outbound IPsec SAs and their parameters and send
simultaneously the new inbound IPsec SA with SPIa1 and new simultaneously the new inbound IPsec SA with SPIa1 and new
outbound IPsec SAs with SPIb1 to NSF A; and the new inbound outbound IPsec SAs with SPIb1 to NSF A; and the new inbound
IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to
B, together with the corresponding IPsec policies. B, together with the corresponding IPsec policies.
* Once the Security Controller receives confirmation from NSF A * Once the Security Controller receives confirmation from NSF A
and NSF B, the controller knows that the IPsec SAs are and NSF B, the controller knows that the IPsec SAs are
correctly installed and ready. correctly installed and ready.
skipping to change at page 29, line 34 skipping to change at page 29, line 34
9.3. YANG modules 9.3. YANG modules
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8446] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in these YANG modules that There are a number of data nodes defined in these YANG modules that
are writable/creatable/deletable (i.e., config true, which is the are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
skipping to change at page 32, line 5 skipping to change at page 31, line 49
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
skipping to change at page 32, line 33 skipping to change at page 32, line 22
Carrel, D. and B. Weiss, "IPsec Key Exchange using a Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019. in progress), March 2019.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019. progress), July 2019.
[I-D.ietf-opsawg-nat-yang]
Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula,
S., and Q. Wu, "A YANG Module for Network Address
Translation (NAT) and Network Prefix Translation (NPT)",
draft-ietf-opsawg-nat-yang-17 (work in progress),
September 2018.
[I-D.tran-ipsecme-yang] [I-D.tran-ipsecme-yang]
Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data
Model for Internet Protocol Security (IPsec)", draft-tran- Model for Internet Protocol Security (IPsec)", draft-tran-
ipsecme-yang-01 (work in progress), June 2015. ipsecme-yang-01 (work in progress), June 2015.
[ITU-T.X.1252] [ITU-T.X.1252]
"Baseline Identity Management Terms and Definitions", "Baseline Identity Management Terms and Definitions",
April 2010. April 2010.
[ITU-T.X.800] [ITU-T.X.800]
"Security Architecture for Open Systems Interconnection "Security Architecture for Open Systems Interconnection
for CCITT Applications", March 1991. for CCITT Applications", March 1991.
[ITU-T.Y.3300] [ITU-T.Y.3300]
"Recommendation ITU-T Y.3300", June 2014. "Recommendation ITU-T Y.3300", June 2014.
[libreswan] [libreswan]
The Libreswan Project, "Libreswan VPN software", July The Libreswan Project, "Libreswan VPN software", August
2019. 2019.
[netconf-vpn] [netconf-vpn]
Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014.
[ONF-OpenFlow] [ONF-OpenFlow]
ONF, "OpenFlow Switch Specification (Version 1.4.0)", ONF, "OpenFlow Switch Specification (Version 1.4.0)",
October 2013. October 2013.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
skipping to change at page 34, line 11 skipping to change at page 33, line 39
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>.
[strongswan] [strongswan]
CESNET, "StrongSwan: the OpenSource IPsec-based VPN CESNET, "StrongSwan: the OpenSource IPsec-based VPN
Solution", July 2019. Solution", August 2019.
Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases
<CODE BEGINS> file "ietf-ipsec-common@2019-07-07.yang" <CODE BEGINS> file "ietf-ipsec-common@2019-08-05.yang"
module ietf-ipsec-common { module ietf-ipsec-common {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common";
prefix "ipsec-common"; prefix "ipsec-common";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
skipping to change at page 36, line 6 skipping to change at page 36, line 6
IETF Trust's Legal Provisions Relating to IETF Documents IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;; This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision "2019-07-07" { revision "2019-08-05" {
description "Revision 05"; description "Revision 06";
reference "RFC XXXX: YANG Groupings and typedef reference "RFC XXXX: YANG Groupings and typedef
for IKE and IKE-less case"; for IKE and IKE-less case";
} }
typedef encryption-algorithm-type { typedef encryption-algorithm-type {
type uint16; type uint16;
description description
"The encryption algorithm is specified with a 16-bit "The encryption algorithm is specified with a 16-bit
number extracted from IANA Registry. The acceptable number extracted from IANA Registry. The acceptable
values MUST follow the requirement levels for values MUST follow the requirement levels for
skipping to change at page 46, line 31 skipping to change at page 46, line 31
default false; default false;
description description
"The flag indicating whether "The flag indicating whether
overflow of the sequence number overflow of the sequence number
counter should prevent transmission counter should prevent transmission
of additional packets on the IPsec of additional packets on the IPsec
SA (false) and, therefore needs to SA (false) and, therefore needs to
be rekeyed, or whether rollover is be rekeyed, or whether rollover is
permitted (true). If Authenticated permitted (true). If Authenticated
Encryption with Associated Data Encryption with Associated Data
(AEAD) is used this flag MUST BE (AEAD) is used this flag MUST be
false."; false.";
} }
leaf stateful-frag-check { leaf stateful-frag-check {
type boolean; type boolean;
default false; default false;
description description
"Indicates whether (true) or not (false) "Indicates whether (true) or not (false)
stateful fragment checking applies to stateful fragment checking applies to
the IPsec SA to be created."; the IPsec SA to be created.";
} }
skipping to change at page 48, line 46 skipping to change at page 48, line 46
states."; states.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Appendix B. Appendix B: YANG model for IKE case Appendix B. Appendix B: YANG model for IKE case
<CODE BEGINS> file "ietf-ipsec-ike@2019-07-07.yang" <CODE BEGINS> file "ietf-ipsec-ike@2019-08-05.yang"
module ietf-ipsec-ike { module ietf-ipsec-ike {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike";
prefix "ike"; prefix "ike";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
import ietf-crypto-types { import ietf-crypto-types {
prefix ct; prefix ct;
reference reference
"draft-ietf-netconf-crypto-types-09: "draft-ietf-netconf-crypto-types-10:
Common YANG Data Types for Cryptography."; Common YANG Data Types for Cryptography.";
} }
import ietf-ipsec-common { import ietf-ipsec-common {
prefix ic; prefix ic;
reference reference
"RFC XXXX: module ietf-ipsec-common, revision "RFC XXXX: module ietf-ipsec-common, revision
2019-07-07."; 2019-08-05.";
} }
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference reference
"RFC 8341: Network Configuration Access Control "RFC 8341: Network Configuration Access Control
Model."; Model.";
} }
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
skipping to change at page 50, line 24 skipping to change at page 50, line 24
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices. the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision "2019-07-07" { revision "2019-08-05" {
description "Revision 5"; description "Revision 6";
reference reference
"RFC XXXX: YANG model for IKE case."; "RFC XXXX: YANG model for IKE case.";
} }
typedef ike-spi { typedef ike-spi {
type uint64 { range "0..max"; } type uint64 { range "0..max"; }
description description
"Security Parameter Index (SPI)'s IKE SA."; "Security Parameter Index (SPI)'s IKE SA.";
reference reference
"Section 2.6 in RFC 7296."; "Section 2.6 in RFC 7296.";
skipping to change at page 53, line 42 skipping to change at page 53, line 42
identified by one of these identities. identified by one of these identities.
This peer can be a remote peer or local This peer can be a remote peer or local
peer (this NSF)."; peer (this NSF).";
reference reference
"Section 4.4.3.1 in RFC 4301."; "Section 4.4.3.1 in RFC 4301.";
case ipv4-address{ case ipv4-address{
leaf ipv4-address { leaf ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description description
"Specifies the identity as a "Specifies the identity as a
single four (4) octet IPv4 single four (4) octet.";
addressExample: 10.10.10.10.";
} }
} }
case ipv6-address{ case ipv6-address{
leaf ipv6-address { leaf ipv6-address {
type inet:ipv6-address; type inet:ipv6-address;
description description
"Specifies the identity as a "Specifies the identity as a
single sixteen (16) octet IPv6 single sixteen (16) octet IPv6
address. An example is address. An example is
2001:DB8:0:0:8:800:200C:417A."; 2001:DB8:0:0:8:800:200C:417A.";
} }
} }
case fqdn-string { case fqdn-string {
leaf fqdn-string { leaf fqdn-string {
type inet:domain-name; type inet:domain-name;
description description
"Specifies the identity as a "Specifies the identity as a
Fully-QualifiedDomain Name Fully-QualifiedDomain Name
(FQDN) string. An example is: (FQDN) string. An example is:
example.com. The string MUST example.com. The string MUST
not contain any terminators NOT contain any terminators
(e.g., NULL, CR, etc.)."; (e.g., NULL, CR, etc.).";
} }
} }
case rfc822-address-string { case rfc822-address-string {
leaf rfc822-address-string { leaf rfc822-address-string {
type string; type string;
description description
"Specifies the identity as a "Specifies the identity as a
fully-qualified RFC822 email fully-qualified RFC822 email
address string. An example is, address string. An example is,
jsmith@example.com. The string jsmith@example.com. The string
MUST not contain any MUST NOT contain any
terminators e.g., NULL, CR, terminators e.g., NULL, CR,
etc.)."; etc.).";
reference reference
"RFC 822."; "RFC 822.";
} }
} }
case dnx509 { case dnx509 {
leaf dnx509 { leaf dnx509 {
type string; type string;
description description
skipping to change at page 67, line 21 skipping to change at page 67, line 21
particular, it provides the current number of particular, it provides the current number of
IKE SAs."; IKE SAs.";
} }
} /* container ipsec-ike */ } /* container ipsec-ike */
} }
<CODE ENDS> <CODE ENDS>
Appendix C. Appendix C: YANG model for IKE-less case Appendix C. Appendix C: YANG model for IKE-less case
<CODE BEGINS> file "ietf-ipsec-ikeless@2019-07-07.yang" <CODE BEGINS> file "ietf-ipsec-ikeless@2019-08-05.yang"
module ietf-ipsec-ikeless { module ietf-ipsec-ikeless {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless";
prefix "ikeless"; prefix "ikeless";
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
skipping to change at page 68, line 40 skipping to change at page 68, line 40
IETF Trust's Legal Provisions Relating to IETF Documents IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;; This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices. see the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14 document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision "2019-07-07" { revision "2019-08-05" {
description "Revision 05"; description "Revision 06";
reference "RFC XXXX: YANG model for IKE case."; reference "RFC XXXX: YANG model for IKE case.";
} }
container ipsec-ikeless { container ipsec-ikeless {
description description
"Container for configuration of the IKE-less "Container for configuration of the IKE-less
case. The container contains two additional case. The container contains two additional
containers: 'spd' and 'sad'. The first allows the containers: 'spd' and 'sad'. The first allows the
Security Controller to configure IPsec policies in Security Controller to configure IPsec policies in
the Security Policy Database SPD, and the second the Security Policy Database SPD, and the second
skipping to change at page 78, line 18 skipping to change at page 78, line 18
/ \ / \
/ \ / \
/ \ / \
/ \ / \
nsf_h1 nsf_h2 nsf_h1 nsf_h2
h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2 h1---- (:1/:100)===== IPsec_ESP_Tunnel_mode =====(:200/:1)-------h2
2001:DB8:1:/64 (2001:DB8:123:/64) 2001:DB8:2:/64 2001:DB8:1:/64 (2001:DB8:123:/64) 2001:DB8:2:/64
Figure 7: IKE case, tunnel mode , X.509 certicate authentication. Figure 7: IKE case, tunnel mode , X.509 certicate authentication.
<ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike" <ipsec-ike xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<pad> <pad>
<pad-entry> <pad-entry>
<name>nsf_h1_pad</name> <name>nsf_h1_pad</name>
<ipv6-address>2001:DB8:123::100</ipv6-address> <ipv6-address>2001:DB8:123::100</ipv6-address>
<peer-authentication> <peer-authentication>
<auth-method>digital-signature</auth-method> <auth-method>digital-signature</auth-method>
<digital-signature> <digital-signature>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
<private-key>base64encodedvalue==</private-key> <private-key>base64encodedvalue==</private-key>
<ca-data>base64encodedvalue==</ca-data> <ca-data>base64encodedvalue==</ca-data>
</digital-signature> </digital-signature>
</peer-authentication> </peer-authentication>
</pad-entry> </pad-entry>
<pad-entry> <pad-entry>
<name>nsf_h2_pad</name> <name>nsf_h2_pad</name>
<ipv6-address>2001:DB8:123::200</ipv6-address> <ipv6-address>2001:DB8:123::200</ipv6-address>
<auth-protocol>ikev2</auth-protocol> <auth-protocol>ikev2</auth-protocol>
<peer-authentication> <peer-authentication>
<auth-method>digital-signature</auth-method> <auth-method>digital-signature</auth-method>
<digital-signature> <digital-signature>
<!-- RSA Digital Signature --> <!-- RSA Digital Signature -->
<ds-algorithm>1</ds-algorithm> <ds-algorithm>1</ds-algorithm>
<cert-data>base64encodedvalue==</cert-data> <cert-data>base64encodedvalue==</cert-data>
<ca-data>base64encodedvalue==</ca-data> <ca-data>base64encodedvalue==</ca-data>
</digital-signature> </digital-signature>
</peer-authentication> </peer-authentication>
</pad-entry> </pad-entry>
</pad> </pad>
<conn-entry> <conn-entry>
<name>nsf_h1-nsf_h2</name> <name>nsf_h1-nsf_h2</name>
<autostartup>start</autostartup> <autostartup>start</autostartup>
<version>ikev2</version> <version>ikev2</version>
<initial-contact>false</initial-contact> <initial-contact>false</initial-contact>
<fragmentation>true</fragmentation> <fragmentation>true</fragmentation>
<ike-sa-lifetime-soft> <ike-sa-lifetime-soft>
<rekey-time>60</rekey-time> <rekey-time>60</rekey-time>
<reauth-time>120</reauth-time> <reauth-time>120</reauth-time>
</ike-sa-lifetime-soft> </ike-sa-lifetime-soft>
<ike-sa-lifetime-hard> <ike-sa-lifetime-hard>
<over-time>3600</over-time> <over-time>3600</over-time>
</ike-sa-lifetime-hard> </ike-sa-lifetime-hard>
<authalg>7</authalg> <authalg>7</authalg>
<!--AUTH_HMAC_SHA1_160--> <!--AUTH_HMAC_SHA1_160-->
<encalg>3</encalg> <encalg>3</encalg>
<!--ENCR_3DES --> <!--ENCR_3DES -->
<dh-group>18</dh-group> <dh-group>18</dh-group>
<!--8192-bit MODP Group--> <!--8192-bit MODP Group-->
<half-open-ike-sa-timer>30</half-open-ike-sa-timer> <half-open-ike-sa-timer>30</half-open-ike-sa-timer>
<half-open-ike-sa-cookie-threshold>15</half-open-ike-sa-cookie-threshold> <half-open-ike-sa-cookie-threshold>
<local> 15
<local-pad-entry-name>nsf_h1_pad</local-pad-entry-name> </half-open-ike-sa-cookie-threshold>
</local> <local>
<remote> <local-pad-entry-name>nsf_h1_pad</local-pad-entry-name>
<remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name> </local>
</remote> <remote>
<spd> <remote-pad-entry-name>nsf_h2_pad</remote-pad-entry-name>
<spd-entry> </remote>
<name>nsf_h1-nsf_h2</name> <spd>
<ipsec-policy-config> <spd-entry>
<anti-replay-window>32</anti-replay-window> <name>nsf_h1-nsf_h2</name>
<traffic-selector> <ipsec-policy-config>
<local-subnet>2001:DB8:1::0/64</local-subnet> <anti-replay-window>32</anti-replay-window>
<remote-subnet>2001:DB8:2::0/64</remote-subnet> <traffic-selector>
<inner-protocol>any</inner-protocol> <local-subnet>2001:DB8:1::0/64</local-subnet>
<local-ports> <remote-subnet>2001:DB8:2::0/64</remote-subnet>
<start>0</start> <inner-protocol>any</inner-protocol>
<end>0</end> <local-ports>
</local-ports> <start>0</start>
<remote-ports> <end>0</end>
<start>0</start> </local-ports>
<end>0</end> <remote-ports>
</remote-ports> <start>0</start>
</traffic-selector> <end>0</end>
<processing-info> </remote-ports>
<action>protect</action> </traffic-selector>
<ipsec-sa-cfg> <processing-info>
<pfp-flag>false</pfp-flag> <action>protect</action>
<ext-seq-num>true</ext-seq-num> <ipsec-sa-cfg>
<seq-overflow>false</seq-overflow> <pfp-flag>false</pfp-flag>
<stateful-frag-check>false</stateful-frag-check> <ext-seq-num>true</ext-seq-num>
<mode>tunnel</mode> <seq-overflow>false</seq-overflow>
<protocol-parameters>esp</protocol-parameters> <stateful-frag-check>false</stateful-frag-check>
<esp-algorithms> <mode>tunnel</mode>
<!-- AUTH_HMAC_SHA1_96 --> <protocol-parameters>esp</protocol-parameters>
<integrity>2</integrity> <esp-algorithms>
<!-- ENCR_AES_CBC --> <!-- AUTH_HMAC_SHA1_96 -->
<encryption>12</encryption> <integrity>2</integrity>
<tfc-pad>false</tfc-pad> <!-- ENCR_AES_CBC -->
</esp-algorithms> <encryption>12</encryption>
<tunnel> <tfc-pad>false</tfc-pad>
<local>2001:DB8:123::100</local> </esp-algorithms>
<remote>2001:DB8:123::200</remote> <tunnel>
<df-bit>clear</df-bit> <local>2001:DB8:123::100</local>
<bypass-dscp>true</bypass-dscp> <remote>2001:DB8:123::200</remote>
<ecn>false</ecn> <df-bit>clear</df-bit>
</tunnel> <bypass-dscp>true</bypass-dscp>
</ipsec-sa-cfg> <ecn>false</ecn>
</processing-info> </tunnel>
</ipsec-policy-config> </ipsec-sa-cfg>
</spd-entry> </processing-info>
</spd> </ipsec-policy-config>
<child-sa-info> </spd-entry>
<!--8192-bit MODP Group --> </spd>
<pfs-groups>18</pfs-groups> <child-sa-info>
<child-sa-lifetime-soft> <!--8192-bit MODP Group -->
<bytes>1000000</bytes> <pfs-groups>18</pfs-groups>
<packets>1000</packets> <child-sa-lifetime-soft>
<time>30</time> <bytes>1000000</bytes>
<idle>60</idle> <packets>1000</packets>
<action>replace</action> <time>30</time>
</child-sa-lifetime-soft> <idle>60</idle>
<child-sa-lifetime-hard> <action>replace</action>
<bytes>2000000</bytes> </child-sa-lifetime-soft>
<packets>2000</packets> <child-sa-lifetime-hard>
<time>60</time> <bytes>2000000</bytes>
<idle>120</idle> <packets>2000</packets>
</child-sa-lifetime-hard> <time>60</time>
</child-sa-info> <idle>120</idle>
</conn-entry> </child-sa-lifetime-hard>
</ipsec-ike> </child-sa-info>
</conn-entry>
</ipsec-ike>
Appendix E. Example of IKE-less case, transport mode (host-to-host). Appendix E. Example of IKE-less case, transport mode (host-to-host).
This example shows a XML configuration file sent by the Security This example shows a XML configuration file sent by the Security
Controller to establish a IPsec Security association between two NSFs Controller to establish a IPsec Security association between two NSFs
in transport mode (host-to-host) with ESP. in transport mode (host-to-host) with ESP.
Security Controller Security Controller
| |
/---- Southbound interface -----\ /---- Southbound interface -----\
skipping to change at page 85, line 7 skipping to change at page 85, line 12
</sad> </sad>
</ipsec-ikeless> </ipsec-ikeless>
Appendix F. Examples of notifications. Appendix F. Examples of notifications.
Below we show several XML files that represent different types of Below we show several XML files that represent different types of
notifications defined in the IKE-less YANG model, which are sent by notifications defined in the IKE-less YANG model, which are sent by
the NSF to the Security Controller. The notifications happen in the the NSF to the Security Controller. The notifications happen in the
IKE-less case. IKE-less case.
<sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <sadb-expire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-sa-name> <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
<soft-lifetime-expire>true</soft-lifetime-expire> </ipsec-sa-name>
<lifetime-current> <soft-lifetime-expire>true</soft-lifetime-expire>
<bytes>1000000</bytes> <lifetime-current>
<packets>1000</packets> <bytes>1000000</bytes>
<time>30</time> <packets>1000</packets>
<idle>60</idle> <time>30</time>
</lifetime-current> <idle>60</idle>
</sadb-expire> </lifetime-current>
</sadb-expire>
Figure 9: Example of sadb-expire notification. Figure 9: Example of sadb-expire notification.
<sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <sadb-acquire xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-policy-name> <ipsec-policy-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
<traffic-selector> </ipsec-policy-name>
<local-subnet>2001:DB8:123::200/128</local-subnet> <traffic-selector>
<remote-subnet>2001:DB8:123::100/128</remote-subnet> <local-subnet>2001:DB8:123::200/128</local-subnet>
<inner-protocol>any</inner-protocol> <remote-subnet>2001:DB8:123::100/128</remote-subnet>
<local-ports> <inner-protocol>any</inner-protocol>
<start>0</start> <local-ports>
<end>0</end> <start>0</start>
</local-ports> <end>0</end>
<remote-ports> </local-ports>
<start>0</start> <remote-ports>
<end>0</end> <start>0</start>
</remote-ports> <end>0</end>
</traffic-selector> </remote-ports>
</sadb-acquire> </traffic-selector>
</sadb-acquire>
Figure 10: Example of sadb-acquire notification. Figure 10: Example of sadb-acquire notification.
<sadb-seq-overflow xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> <sadb-seq-overflow
<ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100</ipsec-sa-name> xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
</sadb-seq-overflow> <ipsec-sa-name>in/trans/2001:DB8:123::200/2001:DB8:123::100
</ipsec-sa-name>
</sadb-seq-overflow>
Figure 11: Example of sadb-seq-overflow notification. Figure 11: Example of sadb-seq-overflow notification.
<sadb-bad-spi <sadb-bad-spi
xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"> xmlns="urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless">
<spi>666</spi> <spi>666</spi>
</sadb-bad-spi> </sadb-bad-spi>
Figure 12: Example of sadb-bad-spi notification. Figure 12: Example of sadb-bad-spi notification.
 End of changes. 43 change blocks. 
378 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/