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/