draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-12.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: April 25, 2021 F. Pereniguez-Garcia Expires: May 3, 2021 F. Pereniguez-Garcia
University Defense Center University Defense Center
October 22, 2020 October 30, 2020
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 draft-ietf-i2nsf-sdn-ipsec-flow-protection-12
Abstract Abstract
This document describes how to provide IPsec-based flow protection This document describes how to provide IPsec-based flow protection
(integrity and confidentiality) by means of an Interface to Network (integrity and confidentiality) by means of an Interface to Network
Security Function (I2NSF) controller. It considers two main well- Security Function (I2NSF) controller. It considers two main well-
known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to-
host. The service described in this document allows the host. The service described in this document allows the
configuration and monitoring of IPsec Security Associations (SAs) configuration and monitoring of IPsec Security Associations (SAs)
from a I2NSF Controller to one or several flow-based Network Security from a I2NSF Controller to one or several flow-based Network Security
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 April 25, 2021. This Internet-Draft will expire on May 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 45 skipping to change at page 2, line 45
6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24
8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Common YANG model for IKE and IKE-less cases . . . . 31 Appendix A. Common YANG model for IKE and IKE-less cases . . . . 32
Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 46 Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 47
Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 65 Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 66
Appendix D. XML configuration example for IKE case (gateway-to- Appendix D. XML configuration example for IKE case (gateway-to-
gateway) . . . . . . . . . . . . . . . . . . . . . . 76 gateway) . . . . . . . . . . . . . . . . . . . . . . 77
Appendix E. XML configuration example for IKE-less case (host- Appendix E. XML configuration example for IKE-less case (host-
to-host) . . . . . . . . . . . . . . . . . . . . . . 80 to-host) . . . . . . . . . . . . . . . . . . . . . . 80
Appendix F. XML notification examples . . . . . . . . . . . . . 84 Appendix F. XML notification examples . . . . . . . . . . . . . 85
Appendix G. Operational use cases examples . . . . . . . . . . . 86 Appendix G. Operational use cases examples . . . . . . . . . . . 86
G.1. Example of IPsec SA establishment . . . . . . . . . . . . 86 G.1. Example of IPsec SA establishment . . . . . . . . . . . . 86
G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 86 G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 87
G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 88 G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 89
G.2. Example of the rekeying process in IKE-less case . . . . 90 G.2. Example of the rekeying process in IKE-less case . . . . 91
G.3. Example of managing NSF state loss in IKE-less case . . . 91 G.3. Example of managing NSF state loss in IKE-less case . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
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 centralized entity, namely SDN Controller. of network resources to a centralized entity, namely SDN Controller.
SDN controllers configure and manage distributed network resources SDN controllers configure and manage distributed network resources
and provide an abstracted view of the network resources to SDN and provide an abstracted view of the network resources to SDN
applications. SDN applications can customize and automate the applications. SDN applications can customize and automate the
skipping to change at page 5, line 13 skipping to change at page 5, line 13
the I2NSF Controller and the NSF. Using YANG data modelling language the I2NSF Controller and the NSF. Using YANG data modelling language
version 1.1 [RFC7950] and based on YANG models defined in version 1.1 [RFC7950] and based on YANG models defined in
[netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC
7296 [RFC7296], this document defines the required interfaces with a 7296 [RFC7296], this document defines the required interfaces with a
YANG model for configuration and state data for IKE, PAD, SPD and SAD YANG model for configuration and state data for IKE, PAD, SPD and SAD
(see Appendix A, Appendix B and Appendix C). The proposed YANG data (see Appendix A, Appendix B and Appendix C). The proposed YANG data
model conforms to the Network Management Datastore Architecture model conforms to the Network Management Datastore Architecture
(NMDA) defined in [RFC8342]. Examples of the usage of these models (NMDA) defined in [RFC8342]. Examples of the usage of these models
can be found in Appendix D, Appendix E and Appendix F. can be found in Appendix D, Appendix E and Appendix F.
In summary, the objetives of this I-D are: In summary, the objectives of this document are:
o To describe the architecture for the I2NSF-based IPsec management, o To describe the architecture for the I2NSF-based IPsec management,
which allows the establishment and management of IPsec security which allows the establishment and management of IPsec security
associations from the I2NSF Controller in order to protect associations from the I2NSF Controller in order to protect
specific data flows between two flow-based NSFs implementing specific data flows between two flow-based NSFs implementing
IPsec. IPsec.
o To map this architecture to the I2NSF Framework. o To map this architecture to the I2NSF Framework.
o To define the interfaces required to manage and monitor the IPsec o To define the interfaces required to manage and monitor the IPsec
SAs in the NSF from a I2NSF Controller. YANG data models are SAs in the NSF from a I2NSF Controller. YANG data models are
defined for configuration and state data for IPsec and IKEv2 defined for configuration and state data for IPsec and IKEv2
management through the I2NSF NSF-Facing interface. Thus, this I-D management through the I2NSF NSF-Facing interface. Thus, this
does not define any new protocol. document does not define any new protocol.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in BCP
2119 [RFC2119]. When these words appear in lower case, they have 14 [RFC2119] [RFC8174] when, and only when, they appear in all
their natural language meaning. capitals, as shown here.
3. Terminology 3. Terminology
This document uses the terminology described in [RFC8329], [RFC8192], This document uses the terminology described in [RFC8329], [RFC8192],
[RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term
is defined in [ITU-T.Y.3300]: is defined in [ITU-T.Y.3300]:
o Software-Defined Networking. o Software-Defined Networking.
The following terms are in defined in [RFC8192]: The following terms are in defined in [RFC8192]:
skipping to change at page 14, line 14 skipping to change at page 14, line 14
| +--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? binary
| +--rw private-key? binary | +--rw private-key? binary
| +--rw ca-data* ct:x509 | +--rw ca-data* binary
| +--rw crl-data? ct:crl | +--rw crl-data? binary
| +--rw crl-uri? inet:uri | +--rw crl-uri? inet:uri
| +--rw oscp-uri? inet:uri | +--rw oscp-uri? inet:uri
+--rw conn-entry* [name] +--rw conn-entry* [name]
| +--rw name string | +--rw name string
| +--rw autostartup? autostartup-type | +--rw autostartup? autostartup-type
| +--rw initial-contact? boolean | +--rw initial-contact? boolean
| +--rw version? auth-protocol-type | +--rw version? auth-protocol-type
| +--rw fragmentation? boolean | +--rw fragmentation? boolean
| +--rw ike-sa-lifetime-soft | +--rw ike-sa-lifetime-soft
| | +--rw rekey-time? uint32 | | +--rw rekey-time? uint32
skipping to change at page 15, line 36 skipping to change at page 15, line 36
| | | | +--rw encryption* [id] | | | | +--rw encryption* [id]
| | | | | +--rw id uint8 | | | | | +--rw id uint8
| | | | | +--rw algorithm-type? nsfikec:encryption-algorithm-type | | | | | +--rw algorithm-type? nsfikec:encryption-algorithm-type
| | | | | +--rw key-length? uint16 | | | | | +--rw key-length? uint16
| | | | +--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* inet:dscp
| | | +--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
skipping to change at page 19, line 17 skipping to change at page 19, line 17
| | | +--rw encryption* [id] | | | +--rw encryption* [id]
| | | |+--rw id uint8 | | | |+--rw id uint8
| | | |+--rw algorithm-type? nsfikec:encryption-algorithm-type | | | |+--rw algorithm-type? nsfikec:encryption-algorithm-type
| | | |+--rw key-length? uint16 | | | |+--rw key-length? uint16
| | | +--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* inet:dscp
| | +--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
skipping to change at page 20, line 20 skipping to change at page 20, line 20
| | +--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? nsfikec:lifetime-action | | +--rw action? nsfikec: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* inet:dscp
| | +--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
skipping to change at page 26, line 18 skipping to change at page 26, line 18
David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin
Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J.
Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio
Martinez, Ruben Ricart and Roman Danyliw for their valuable comments. Martinez, Ruben Ricart and Roman Danyliw for their valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.draft-ietf-netconf-crypto-types] [IANA-Protocols-Number]
Watsen, K., "YANG Data Types and Groupings for Internet Assigned Numbers Authority (IANA), "Protocol
Cryptography", draft-ietf-netconf-crypto-types-18 (work in Numbers", January 2020, <https://www.iana.org/assignments/
progress), August 2020. protocol-numbers/protocol-numbers.xhtml>.
[IKEv2-Auth-Method]
Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters - IKEv2
Authentication Method", August 2020,
<https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-12>.
[IKEv2-Parameters] [IKEv2-Parameters]
Internet Assigned Numbers Authority (IANA), "Internet Key Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters", August 2020. Exchange Version 2 (IKEv2) Parameters", August 2020,
<https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml>.
[IKEv2-Transform-Type-1]
Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters - Transform Type
Values - Transform Type 1 - Encryption Algorithm Transform
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
5>.
[IKEv2-Transform-Type-3]
Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters - Transform Type
Values - Transform Type 3 - Integrity Algorithm Transform
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
7>.
[IKEv2-Transform-Type-4]
Internet Assigned Numbers Authority (IANA), "Internet Key
Exchange Version 2 (IKEv2) Parameters - Transform Type
Values - Transform Type 4 - Diffie-Hellman Group Transform
IDs", August 2020, <https://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-
8>.
[ITU-T.X.690] [ITU-T.X.690]
"Recommendation ITU-T X.690", August 2015. "Recommendation ITU-T X.690", August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
skipping to change at page 27, line 11 skipping to change at page 27, line 45
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010,
<https://www.rfc-editor.org/info/rfc5915>. <https://www.rfc-editor.org/info/rfc5915>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
skipping to change at page 31, line 10 skipping to change at page 32, line 10
[strongswan] [strongswan]
CESNET, "StrongSwan: the OpenSource IPsec-based VPN CESNET, "StrongSwan: the OpenSource IPsec-based VPN
Solution", September 2020. Solution", September 2020.
Appendix A. Common YANG model for IKE and IKE-less cases Appendix A. Common YANG model for IKE and IKE-less cases
This Appendix is Normative. This Appendix is Normative.
This YANG module has normative references to [RFC3947], [RFC4301], This YANG module has normative references to [RFC3947], [RFC4301],
[RFC4303], [RFC8174], [RFC8221] and [IKEv2-Parameters]. [RFC4303], [RFC8174], [RFC8221], [IANA-Protocols-Number],
[IKEv2-Parameters], [IKEv2-Transform-Type-1] and
[IKEv2-Transform-Type-3].
This YANG module has informative references to [RFC3948] and This YANG module has informative references to [RFC3948] and
[RFC8229]. [RFC8229].
<CODE BEGINS> file "ietf-i2nsf-ikec@2020-10-22.yang" <CODE BEGINS> file "ietf-i2nsf-ikec@2020-10-30.yang"
module ietf-i2nsf-ikec {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
prefix "nsfikec";
import ietf-inet-types { module ietf-i2nsf-ikec {
prefix inet; yang-version 1.1;
reference "RFC 6991: Common YANG Data Types"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec";
} prefix "nsfikec";
import ietf-yang-types { import ietf-inet-types {
prefix yang; prefix inet;
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
} }
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> "WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez Author: Rafael Marin-Lopez
<mailto:rafa@um.es> <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es> <mailto:fernando.pereniguez@cud.upct.es>
"; ";
description
"Common Data model for the IKE and IKE-less cases
defined by the SDN-based IPsec flow protection service.
Copyright (c) 2020 IETF Trust and the persons
identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;;
see the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', description
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', "Common Data model for the IKE and IKE-less cases
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this defined by the SDN-based IPsec flow protection service.
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
revision "2020-10-22" { Copyright (c) 2020 IETF Trust and the persons
description "Initial version."; identified as authors of the code. All rights reserved.
reference "RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
typedef encryption-algorithm-type { Redistribution and use in source and binary forms, with
type uint16; or without modification, is permitted pursuant to, and
description subject to the license terms contained in, the
"The encryption algorithm is specified with a 16-bit Simplified BSD License set forth in Section 4.c of the
number extracted from IANA Registry. The acceptable IETF Trust's Legal Provisions Relating to IETF Documents
values MUST follow the requirement levels for (https://trustee.ietf.org/license-info).
encryption algorithms for ESP and IKEv2.";
reference
"IANA Registry- Transform Type 1 - Encryption
Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef integrity-algorithm-type { This version of this YANG module is part of RFC XXXX;;
type uint16; see the RFC itself for full legal notices.
description
"The integrity algorithm is specified with a 16-bit
number extracted from IANA Registry.
The acceptable values MUST follow the requirement The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
levels for encryption algorithms for ESP and IKEv2."; 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
reference 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
"IANA Registry- Transform Type 3 - Integrity document are to be interpreted as described in BCP 14
Algorithm Transform IDs. RFC 8221 - Cryptographic (RFC 2119) (RFC 8174) when, and only when, they appear
Algorithm Implementation Requirements and Usage in all capitals, as shown here.";
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
typedef ipsec-mode { revision "2020-10-30" {
type enumeration { description "Initial version.";
enum transport { reference "RFC XXXX: Software-Defined Networking
description (SDN)-based IPsec Flow Protection.";
"IPsec transport mode. No Network Address }
Translation (NAT) support.";
}
enum tunnel {
description "IPsec tunnel mode.";
}
}
description
"Type definition of IPsec mode: transport or
tunnel.";
reference
"Section 3.2 in RFC 4301.";
}
typedef esp-encap { typedef encryption-algorithm-type {
type enumeration { type uint16;
enum espintcp { description
description "The encryption algorithm is specified with a 16-bit
"ESP in TCP encapsulation."; number extracted from IANA Registry. The acceptable
reference values MUST follow the requirement levels for
"RFC 8229 - TCP Encapsulation of IKE and encryption algorithms for ESP and IKEv2.";
IPsec Packets."; reference
} "IANA; Internet Key Exchange V2 (IKEv2) Parameters;
enum espintls { Transform Atribute Types; Transform Type 1 - Encryption
description Algorithm Transform IDs. RFC 8221 - Cryptographic
"ESP in TCP encapsulation using TLS."; Algorithm Implementation Requirements and Usage
reference Guidance for Encapsulating Security Payload (ESP)
"RFC 8229 - TCP Encapsulation of IKE and and Authentication Header (AH) and RFC 8247 -
IPsec Packets."; Algorithm Implementation Requirements and Usage
} Guidance for the Internet Key Exchange Protocol
enum espinudp { Version 2 (IKEv2).";
description }
"ESP in UDP encapsulation.";
reference
"RFC 3948 - UDP Encapsulation of IPsec ESP
Packets.";
}
enum none {
description
"NOT ESP encapsulation.";
}
}
description
"Types of ESP encapsulation when Network Address
Translation (NAT) is present between two NSFs.";
reference
"RFC 8229 - TCP Encapsulation of IKE and IPsec
Packets and RFC 3948 - UDP Encapsulation of IPsec
ESP Packets.";
}
typedef ipsec-protocol-parameters { typedef integrity-algorithm-type {
type enumeration { type uint16;
enum esp { description "IPsec ESP protocol."; } description
} "The integrity algorithm is specified with a 16-bit
description number extracted from IANA Registry.
"Only the Encapsulation Security Protocol (ESP) is The acceptable values MUST follow the requirement
supported but it could be extended in the future."; levels for encryption algorithms for ESP and IKEv2.";
reference reference
"RFC 4303- IP Encapsulating Security Payload "IANA; Internet Key Exchange V2 (IKEv2) Parameters;
(ESP)."; Transform Atribute Types; Transform Type 3 - Integrity
Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2).";
}
} typedef ipsec-mode {
type enumeration {
enum transport {
description
"IPsec transport mode. No Network Address
Translation (NAT) support.";
}
enum tunnel {
description "IPsec tunnel mode.";
}
}
description
"Type definition of IPsec mode: transport or
tunnel.";
reference
"Section 3.2 in RFC 4301.";
}
typedef lifetime-action { typedef esp-encap {
type enumeration { type enumeration {
enum terminate-clear { enum espintcp {
description description
"Terminates the IPsec SA and allows the "ESP in TCP encapsulation.";
packets through."; reference
} "RFC 8229 - TCP Encapsulation of IKE and
enum terminate-hold { IPsec Packets.";
description }
"Terminates the IPsec SA and drops the enum espintls {
packets."; description
} "ESP in TCP encapsulation using TLS.";
enum replace { reference
description "RFC 8229 - TCP Encapsulation of IKE and
"Replaces the IPsec SA with a new one: IPsec Packets.";
}
enum espinudp {
description
"ESP in UDP encapsulation.";
reference
"RFC 3948 - UDP Encapsulation of IPsec ESP
Packets.";
}
enum none {
description
"NOT ESP encapsulation.";
}
}
description
"Types of ESP encapsulation when Network Address
Translation (NAT) is present between two NSFs.";
reference
"RFC 8229 - TCP Encapsulation of IKE and IPsec
Packets and RFC 3948 - UDP Encapsulation of IPsec
ESP Packets.";
}
rekey. "; typedef ipsec-protocol-parameters {
} type enumeration {
} enum esp { description "IPsec ESP protocol."; }
description }
"When the lifetime of an IPsec SA expires an action description
needs to be performed over the IPsec SA that "Only the Encapsulation Security Protocol (ESP) is
reached the lifetime. There are three posible supported but it could be extended in the future.";
options: terminate-clear, terminate-hold and reference
replace."; "RFC 4303- IP Encapsulating Security Payload
reference (ESP).";
"Section 4.5 in RFC 4301."; }
}
typedef ipsec-traffic-direction { typedef lifetime-action {
type enumeration { type enumeration {
enum inbound { enum terminate-clear {
description "Inbound traffic."; description
} "Terminates the IPsec SA and allows the
enum outbound { packets through.";
description "Outbound traffic."; }
} enum terminate-hold {
} description
description "Terminates the IPsec SA and drops the
"IPsec traffic direction is defined in two packets.";
directions: inbound and outbound. From a NSF }
perspective inbound means the traffic that enters enum replace {
the NSF and outbound is the traffic that is sent description
from the NSF."; "Replaces the IPsec SA with a new one:
reference rekey. ";
"Section 5 in RFC 4301.";
}
typedef ipsec-spd-action { }
type enumeration { }
enum protect { description
description "When the lifetime of an IPsec SA expires an action
"PROTECT the traffic with IPsec."; needs to be performed over the IPsec SA that
} reached the lifetime. There are three posible
enum bypass { options: terminate-clear, terminate-hold and
description replace.";
"BYPASS the traffic. The packet is forwarded reference
without IPsec protection."; "Section 4.5 in RFC 4301.";
} }
enum discard {
description
"DISCARD the traffic. The IP packet is
discarded.";
}
} typedef ipsec-traffic-direction {
description type enumeration {
"The action when traffic matches an IPsec security enum inbound {
policy. According to RFC 4301 there are three description "Inbound traffic.";
possible values: BYPASS, PROTECT AND DISCARD"; }
reference enum outbound {
"Section 4.4.1 in RFC 4301."; description "Outbound traffic.";
} }
}
description
"IPsec traffic direction is defined in two
directions: inbound and outbound. From a NSF
perspective inbound means the traffic that enters
the NSF and outbound is the traffic that is sent
from the NSF.";
reference
"Section 5 in RFC 4301.";
}
typedef ipsec-inner-protocol { typedef ipsec-spd-action {
type union { type enumeration {
type uint8; enum protect {
type enumeration { description
enum any { "PROTECT the traffic with IPsec.";
value 256; }
description enum bypass {
"Any IP protocol number value."; description
} "BYPASS the traffic. The packet is forwarded
} without IPsec protection.";
} }
default any; enum discard {
description description
"IPsec protection can be applied to specific IP "DISCARD the traffic. The IP packet is
traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) discarded.";
or ANY protocol in the IP packet payload. We }
specify the IP protocol number with an uint8 or }
ANY defining an enumerate with value 256 to description
indicate the protocol number."; "The action when traffic matches an IPsec security
reference policy. According to RFC 4301 there are three
"Section 4.4.1.1 in RFC 4301. possible values: BYPASS, PROTECT AND DISCARD";
IANA Registry - Protocol Numbers."; reference
} "Section 4.4.1 in RFC 4301.";
}
grouping encap { typedef ipsec-inner-protocol {
description type union {
"This group of nodes allows to define the type of type uint8;
encapsulation in case NAT traversal is type enumeration {
required and port information."; enum any {
leaf espencap { value 256;
type esp-encap; description
default none; "Any IP protocol number value.";
description }
"ESP in TCP, ESP in UDP or ESP in TLS."; }
} }
leaf sport { default any;
type inet:port-number; description
default 4500; "IPsec protection can be applied to specific IP
description traffic and layer 4 traffic (TCP, UDP, SCTP, etc.)
"Encapsulation source port."; or ANY protocol in the IP packet payload. We
} specify the IP protocol number with an uint8 or
leaf dport { ANY defining an enumerate with value 256 to
type inet:port-number; indicate the protocol number. NOTE: In case
default 4500; of IPv6, the protocol in the IP packet payload
description is specified in the Next Header field of the IPv6
"Encapsulation destination port."; packet.";
} reference
"Section 4.4.1.1 in RFC 4301.
IANA Registry - Protocol Numbers.";
}
leaf-list oaddr { grouping encap {
type inet:ip-address; description
description "This group of nodes allows to define the type of
"If required, this is the original address that encapsulation in case NAT traversal is
was used before NAT was applied over the Packet. required and port information.";
"; leaf espencap {
} type esp-encap;
reference default none;
"RFC 3947 and RFC 8229."; description
} "ESP in TCP, ESP in UDP or ESP in TLS.";
}
leaf sport {
type inet:port-number;
default 4500;
description
"Encapsulation source port.";
}
leaf dport {
type inet:port-number;
default 4500;
description
"Encapsulation destination port.";
}
grouping lifetime { leaf-list oaddr {
description type inet:ip-address;
"Different lifetime values limited to an IPsec SA."; description
leaf time { "If required, this is the original address that
type uint32; was used before NAT was applied over the Packet.
default 0; ";
description }
"Time in seconds since the IPsec SA was added. reference
For example, if this value is 180 seconds it "RFC 3947 and RFC 8229.";
means the IPsec SA expires in 180 seconds since }
it was added. The value 0 implies infinite.";
}
leaf bytes {
type uint32;
default 0;
description
"If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default 0;
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
default 0;
description
"When a NSF stores an IPsec SA, it
consumes system resources. In an idle NSF this
is a waste of resources. If the IPsec SA is idle
during this number of seconds the IPsec SA
should be removed. The value 0 implies
infinite.";
}
reference
"Section 4.4.2.1 in RFC 4301.";
} grouping lifetime {
description
"Different lifetime values limited to an IPsec SA.";
leaf time {
type uint32;
units "seconds";
default 0;
description
"Time in seconds since the IPsec SA was added.
For example, if this value is 180 seconds it
means the IPsec SA expires in 180 seconds since
it was added. The value 0 implies infinite.";
}
leaf bytes {
type uint32;
default 0;
description
"If the IPsec SA processes the number of bytes
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf packets {
type uint32;
default 0;
description
"If the IPsec SA processes the number of packets
expressed in this leaf, the IPsec SA expires and
should be rekeyed. The value 0 implies
infinite.";
}
leaf idle {
type uint32;
units "seconds";
default 0;
description
"When a NSF stores an IPsec SA, it
consumes system resources. In an idle NSF this
is a waste of resources. If the IPsec SA is idle
during this number of seconds the IPsec SA
should be removed. The value 0 implies
infinite.";
}
reference
"Section 4.4.2.1 in RFC 4301.";
}
grouping port-range { grouping port-range {
description description
"This grouping defines a port range, such as "This grouping defines a port range, such as
expressed in RFC 4301. For example: 1500 (Start expressed in RFC 4301. For example: 1500 (Start
Port Number)-1600 (End Port Number). Port Number)-1600 (End Port Number).
A port range is used in the Traffic Selector."; A port range is used in the Traffic Selector.";
leaf start { leaf start {
type inet:port-number; type inet:port-number;
description "Start port number."; description "Start port number.";
} }
leaf end { leaf end {
type inet:port-number; type inet:port-number;
description must '. >= ../start' {
"End port number. The assigned value must be error-message
equal or greater than the start port number. "The end port number MUST be equal or greater
To express a single port, set the same value than the start port number.";
as start and end."; }
} description
reference "Section 4.4.1.2 in RFC 4301."; "End port number. To express a single port, set
} the same value as start and end.";
}
reference "Section 4.4.1.2 in RFC 4301.";
}
grouping tunnel-grouping { grouping tunnel-grouping {
description description
"The parameters required to define the IP tunnel "The parameters required to define the IP tunnel
endpoints when IPsec SA requires tunnel mode. The endpoints when IPsec SA requires tunnel mode. The
tunnel is defined by two endpoints: the local IP tunnel is defined by two endpoints: the local IP
address and the remote IP address."; address and the remote IP address.";
leaf local { leaf local {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Local IP address' tunnel endpoint."; "Local IP address' tunnel endpoint.";
} }
leaf remote { leaf remote {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"Remote IP address' tunnel endpoint."; "Remote IP address' tunnel endpoint.";
} }
leaf df-bit { leaf df-bit {
type enumeration { type enumeration {
enum clear { enum clear {
description description
"Disable the DF (Don't Fragment) bit "Disable the DF (Don't Fragment) bit
from the outer header. This is the from the outer header. This is the
default value."; default value.";
} }
enum set { enum set {
description description
"Enable the DF bit in the outer header."; "Enable the DF bit in the outer header.";
} }
enum copy { enum copy {
description description
"Copy the DF bit to the outer header."; "Copy the DF bit to the outer header.";
} }
} }
default clear; default clear;
description description
"Allow configuring the DF bit when encapsulating "Allow configuring the DF bit when encapsulating
tunnel mode IPsec traffic. RFC 4301 describes tunnel mode IPsec traffic. RFC 4301 describes
three options to handle the DF bit during three options to handle the DF bit during
tunnel encapsulation: clear, set and copy from tunnel encapsulation: clear, set and copy from
the inner IP header."; the inner IP header.";
reference reference
"Section 8.1 in RFC 4301."; "Section 8.1 in RFC 4301.";
} }
leaf bypass-dscp { leaf bypass-dscp {
type boolean; type boolean;
default true; default true;
description description
"If DSCP (Differentiated Services Code Point) "If DSCP (Differentiated Services Code Point)
values in the inner header have to be used to values in the inner header have to be used to
select one IPsec SA among several that match select one IPsec SA among several that match
the traffic selectors for an outbound packet"; the traffic selectors for an outbound packet";
reference reference
"Section 4.4.2.1. in RFC 4301."; "Section 4.4.2.1. in RFC 4301.";
}
leaf-list dscp-mapping {
type inet:dscp;
default 0;
description
"DSCP values allowed for packets carried over
this IPsec SA.";
reference
"Section 4.4.2.1. in RFC 4301.";
}
leaf ecn {
type boolean;
default false;
description
"Explicit Congestion Notification (ECN). If true
copy CE bits to inner header.";
reference
"Section 5.1.2 and Appendix C in RFC 4301.";
}
}
} grouping selector-grouping {
leaf dscp-mapping { description
type yang:hex-string; "This grouping contains the definition of a Traffic
default "00:00:00:00:00:00"; Selector, which is used in the IPsec policies and
description IPsec SAs.";
"DSCP values allowed for packets carried over
this IPsec SA.";
reference
"Section 4.4.2.1. in RFC 4301.";
}
leaf ecn {
type boolean;
default false;
description
"Explicit Congestion Notification (ECN). If true
copy CE bits to inner header.";
reference
"Section 5.1.2 and Annex C in RFC 4301.";
}
}
grouping selector-grouping { leaf local-subnet {
description type inet:ip-prefix;
"This grouping contains the definition of a Traffic mandatory true;
Selector, which is used in the IPsec policies and description
IPsec SAs."; "Local IP address subnet.";
}
leaf remote-subnet {
type inet:ip-prefix;
mandatory true;
description
"Remote IP address subnet.";
}
leaf inner-protocol {
type ipsec-inner-protocol;
default any;
description
"Inner Protocol that is going to be
protected with IPsec.";
}
list local-ports {
key "start end";
uses port-range;
description
"List of local ports. When the inner
protocol is ICMP this 16 bit value
represents code and type.
If this list is not defined
it is assumed that start and
end are 0 by default (any port).";
}
list remote-ports {
key "start end";
uses port-range;
description
"List of remote ports. When the upper layer
protocol is ICMP this 16 bit value represents
code and type.If this list is not defined
it is assumed that start and end are 0 by
default (any port)";
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
leaf local-subnet { grouping ipsec-policy-grouping {
type inet:ip-prefix; description
mandatory true; "Holds configuration information for an IPsec SPD
description entry.";
"Local IP address subnet.";
}
leaf remote-subnet {
type inet:ip-prefix;
mandatory true;
description
"Remote IP address subnet.";
}
leaf inner-protocol {
type ipsec-inner-protocol;
default any;
description
"Inner Protocol that is going to be
protected with IPsec.";
}
list local-ports {
key "start end";
uses port-range;
description
"List of local ports. When the inner
protocol is ICMP this 16 bit value
represents code and type.
If this list is not defined
it is assumed that start and
end are 0 by default (any port).";
}
list remote-ports {
key "start end";
uses port-range;
description
"List of remote ports. When the upper layer
protocol is ICMP this 16 bit value represents
code and type.If this list is not defined
it is assumed that start and end are 0 by
default (any port)";
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
grouping ipsec-policy-grouping { leaf anti-replay-window {
type uint64;
default 32;
description
"A 64-bit counter used to determine whether an
inbound ESP packet is a replay.";
reference
"Section 4.4.2.1 in RFC 4301.";
}
container traffic-selector {
description
"Packets are selected for
processing actions based on the IP and inner
protocol header information, selectors,
matched against entries in the SPD.";
uses selector-grouping;
reference
"Section 4.4.4.1 in RFC 4301.";
}
container processing-info {
description
"SPD processing. If the required processing
action is protect, it contains the required
information to process the packet.";
leaf action {
type ipsec-spd-action;
default discard;
description
"If bypass or discard, container
ipsec-sa-cfg is empty.";
}
container ipsec-sa-cfg {
when "../action = 'protect'";
description
"IPsec SA configuration included in the SPD
entry.";
leaf pfp-flag {
type boolean;
default false;
description description
"Holds configuration information for an IPsec SPD "Each selector has a Populate From
entry."; Packet (PFP) flag. If asserted for a
given selector X, the flag indicates
leaf anti-replay-window { that the IPsec SA to be created should
type uint64; take its value (local IP address,
default 32; remote IP address, Next Layer
description Protocol, etc.) for X from the value
"A 64-bit counter used to determine whether an in the packet. Otherwise, the IPsec SA
inbound ESP packet is a replay."; should take its value(s) for X from
reference the value(s) in the SPD entry.";
"Section 4.4.2.1 in RFC 4301."; }
} leaf ext-seq-num {
container traffic-selector { type boolean;
description default false;
"Packets are selected for description
processing actions based on the IP and inner "True if this IPsec SA is using extended
protocol header information, selectors, sequence numbers. True 64 bit counter,
matched against entries in the SPD."; False 32 bit.";
uses selector-grouping; }
reference leaf seq-overflow {
"Section 4.4.4.1 in RFC 4301."; type boolean;
} default false;
container processing-info { description
description "The flag indicating whether
"SPD processing. If the required processing overflow of the sequence number
action is protect, it contains the required counter should prevent transmission
information to process the packet."; of additional packets on the IPsec
leaf action { SA (false) and, therefore needs to
type ipsec-spd-action; be rekeyed, or whether rollover is
default discard; permitted (true). If Authenticated
description Encryption with Associated Data
"If bypass or discard, container (AEAD) is used (leaf
ipsec-sa-cfg is empty."; esp-algorithms/encryption/algorithm-type)
} this flag MUST be false.";
container ipsec-sa-cfg { }
when "../action = 'protect'"; leaf stateful-frag-check {
description type boolean;
"IPsec SA configuration included in the SPD default false;
entry."; description
leaf pfp-flag { "Indicates whether (true) or not (false)
type boolean; stateful fragment checking applies to
default false; the IPsec SA to be created.";
description }
"Each selector has a Populate From leaf mode {
Packet (PFP) flag. If asserted for a type ipsec-mode;
given selector X, the flag indicates default transport;
that the IPsec SA to be created should description
take its value (local IP address, "IPsec SA has to be processed in
remote IP address, Next Layer transport or tunnel mode.";
Protocol, etc.) for X from the value }
in the packet. Otherwise, the IPsec SA leaf protocol-parameters {
should take its value(s) for X from type ipsec-protocol-parameters;
the value(s) in the SPD entry."; default esp;
} description
leaf ext-seq-num { "Security protocol of the IPsec SA:
type boolean; Only ESP is supported but it could be
default false; extended in the future.";
description }
"True if this IPsec SA is using extended container esp-algorithms {
sequence numbers. True 64 bit counter, when "../protocol-parameters = 'esp'";
False 32 bit."; description
} "Configuration of Encapsulating
leaf seq-overflow { Security Payload (ESP) parameters and
type boolean; algorithms.";
default false;
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore needs to
be rekeyed, or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used this flag MUST be
false.";
}
leaf stateful-frag-check {
type boolean;
default false;
description
"Indicates whether (true) or not (false)
stateful fragment checking applies to
the IPsec SA to be created.";
}
leaf mode {
type ipsec-mode;
default transport;
description
"IPsec SA has to be processed in
transport or tunnel mode.";
}
leaf protocol-parameters {
type ipsec-protocol-parameters;
default esp;
description
"Security protocol of the IPsec SA:
Only ESP is supported but it could be
extended in the future.";
}
container esp-algorithms {
when "../protocol-parameters = 'esp'";
description
"Configuration of Encapsulating
Security Payload (ESP) parameters and
algorithms.";
leaf-list integrity {
type integrity-algorithm-type;
default 0;
ordered-by user;
description
"Configuration of ESP authentication
based on the specified integrity
algorithm. With AEAD algorithms,
the integrity node is not
used.";
reference
"Section 3.2 in RFC 4303.";
} leaf-list integrity {
list encryption { type integrity-algorithm-type;
key id; default 0;
ordered-by user; ordered-by user;
leaf id { description
type uint8; "Configuration of ESP authentication
description based on the specified integrity
"The index of list with the algorithm. With AEAD algorithms,
different encryption algorithms and the integrity node is not used.";
its key-length (if required)."; reference
} "Section 3.2 in RFC 4303.";
leaf algorithm-type { }
type nsfikec:encryption-algorithm-type; list encryption {
default 20; key id;
description ordered-by user;
"Default value 20 (ENCR_AES_GCM_16)"; leaf id {
} type uint8;
leaf key-length { description
type uint16; "The index of list with the
default 128; different encryption algorithms and
description its key-length (if required).";
"By default key length is 128 }
bits"; leaf algorithm-type {
} type nsfikec:encryption-algorithm-type;
description default 20;
"Encryption or AEAD algorithm for the description
IPsec SAs. This list is ordered "Default value 20 (ENCR_AES_GCM_16)";
following from the higher priority to }
lower priority. First node of the leaf key-length {
list will be the algorithm with type uint16;
higher priority. In case the list default 128;
is empty, then description
no encryption algorithm "By default key length is 128
is applied (NULL)."; bits";
reference }
"Section 3.2 in RFC 4303."; description
} "Encryption or AEAD algorithm for the
IPsec SAs. This list is ordered
following from the higher priority to
lower priority. First node of the
list will be the algorithm with
higher priority. In case the list
is empty, then
no encryption algorithm
is applied (NULL).";
reference
"Section 3.2 in RFC 4303.";
}
leaf tfc-pad {
type boolean;
default false;
description
"If Traffic Flow Confidentiality
(TFC) padding for ESP encryption
can be used (true) or not (false)";
reference
"Section 2.7 in RFC 4303.";
}
reference
"RFC 4303.";
}
container tunnel {
when "../mode = 'tunnel'";
uses tunnel-grouping;
description
"IPsec tunnel endpoints definition.";
}
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
container spd-mark {
description
"The Mark to set for the IPsec SA of this
connection. This option is only available
on linux NETKEY/XFRM kernels. It can be
used with iptables to create custom
iptables rules using CONNMARK. It can also
be used with Virtual Tunnel Interfaces
(VTI) to direct marked traffic to
specific vtiXX devices.";
leaf tfc-pad { leaf mark {
type boolean; type uint32;
default false; default 0;
description description
"If Traffic Flow Confidentiality "Mark used to match XFRM policies and
(TFC) padding for ESP encryption states.";
can be used (true) or not (false)"; }
reference leaf mask {
"Section 2.7 in RFC 4303."; type uint32;
} default 0;
reference description
"RFC 4303."; "Mask used to match XFRM policies and
} states.";
container tunnel { }
when "../mode = 'tunnel'"; }
uses tunnel-grouping; }
description }
"IPsec tunnel endpoints definition.";
}
}
reference
"Section 4.4.1.2 in RFC 4301.";
}
container spd-mark {
description
"The Mark to set for the IPsec SA of this
connection. This option is only available
on linux NETKEY/XFRM kernels. It can be
used with iptables to create custom
iptables rules using CONNMARK. It can also
be used with Virtual Tunnel Interfaces
(VTI) to direct marked traffic to
specific vtiXX devices.";
leaf mark {
type uint32;
default 0;
description
"Mark used to match XFRM policies and
states.";
}
leaf mask {
type yang:hex-string;
default 00:00:00:00;
description
"Mask used to match XFRM policies and
states.";
}
}
}
}
<CODE ENDS> <CODE ENDS>
Appendix B. YANG model for IKE case Appendix B. YANG model for IKE case
This Appendix is Normative. This Appendix is Normative.
This YANG module has normative references to [RFC2247], [RFC5280], This YANG module has normative references to [RFC2247], [RFC5280],
[RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383], [RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383],
[RFC7427], [RFC7619], [RFC8017], [RFC8174], [RFC8341], [ITU-T.X.690], [RFC7427], [RFC7619], [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8174],
[I-D.draft-ietf-netconf-crypto-types] and [IKEv2-Parameters]. [IKEv2-Auth-Method], [IKEv2-Transform-Type-4] and [IKEv2-Parameters].
This YANG module has informative references to [RFC8229]. This YANG module has informative references to [RFC8229].
<CODE BEGINS> file "ietf-i2nsf-ike@2020-10-22.yang" <CODE BEGINS> file "ietf-i2nsf-ike@2020-10-30.yang"
module ietf-i2nsf-ike {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
prefix "nsfike";
import ietf-inet-types {
prefix inet;
reference "RFC 6991: Common YANG Data Types";
}
import ietf-yang-types { module ietf-i2nsf-ike {
prefix yang; yang-version 1.1;
reference "RFC 6991: Common YANG Data Types"; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike";
} prefix "nsfike";
import ietf-crypto-types { import ietf-inet-types {
prefix ct; prefix inet;
reference "RFC XXXX: YANG Data Types and Groupings reference "RFC 6991: Common YANG Data Types";
for Cryptography."; }
}
import ietf-i2nsf-ikec { import ietf-yang-types {
prefix nsfikec; prefix yang;
reference reference "RFC 6991: Common YANG Data Types";
"Common Data model for SDN-based IPsec }
configuration.";
}
import ietf-netconf-acm { import ietf-i2nsf-ikec {
prefix nacm; prefix nsfikec;
reference reference
"RFC 8341: Network Configuration Access Control "RFC XXXX: Software-Defined Networking
Model."; (SDN)-based IPsec Flow Protection.";
}
} import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
organization "IETF I2NSF Working Group"; organization "IETF I2NSF Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/> "WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org> WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez Author: Rafael Marin-Lopez
<mailto:rafa@um.es> <mailto:rafa@um.es>
Author: Gabriel Lopez-Millan Author: Gabriel Lopez-Millan
<mailto:gabilm@um.es> <mailto:gabilm@um.es>
Author: Fernando Pereniguez-Garcia Author: Fernando Pereniguez-Garcia
<mailto:fernando.pereniguez@cud.upct.es> <mailto:fernando.pereniguez@cud.upct.es>
"; ";
description
"This module contains IPsec IKE case model for the SDN-based
IPsec flow protection service. An NSF will implement this
module.
Copyright (c) 2020 IETF Trust and the persons identified as description
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or "This module contains IPsec IKE case model for the SDN-based
without modification, is permitted pursuant to, and subject IPsec flow protection service. An NSF will implement this
to the license terms contained in, the Simplified BSD License module.
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see Copyright (c) 2020 IETF Trust and the persons identified as
the RFC itself for full legal notices. authors of the code. All rights reserved.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', Redistribution and use in source and binary forms, with or
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', without modification, is permitted pursuant to, and subject
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this to the license terms contained in, the Simplified BSD License
document are to be interpreted as described in BCP 14 set forth in Section 4.c of the IETF Trust's Legal Provisions
(RFC 2119) (RFC 8174) when, and only when, they appear Relating to IETF Documents
in all capitals, as shown here."; (http://trustee.ietf.org/license-info).
revision "2020-10-22" { This version of this YANG module is part of RFC XXXX; see
description "Initial version."; the RFC itself for full legal notices.
reference "RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
} The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
typedef ike-spi { revision "2020-10-30" {
type uint64 { range "0..max"; } description "Initial version.";
description reference
"Security Parameter Index (SPI)'s IKE SA."; "RFC XXXX: Software-Defined Networking
reference (SDN)-based IPsec Flow Protection.";
"Section 2.6 in RFC 7296."; }
}
typedef autostartup-type { typedef ike-spi {
type enumeration { type uint64 { range "0..max"; }
enum add { description
description "Security Parameter Index (SPI)'s IKE SA.";
"IKE/IPsec configuration is only loaded into reference
IKE implementation but IKE/IPsec SA is not "Section 2.6 in RFC 7296.";
started."; }
}
enum on-demand {
description
"IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies
are transferred to the NSF's kernel but the
IPsec SAs are not established immediately.
The IKE implementation will negotiate the
IPsec SAs when the NSF's kernel requests it
(i.e. through an ACQUIRE notification).";
}
enum start {
description "IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the
IKEv2 based IPsec SAs are established
immediately without waiting any packet.";
}
}
description
"Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has
started.";
}
typedef pfs-group { typedef autostartup-type {
type uint16; type enumeration {
description enum add {
"DH groups for IKE and IPsec SA rekey."; description
reference "IKE/IPsec configuration is only loaded into
"Section 3.3.2 in RFC 7296. Transform Type 4 - IKE implementation but IKE/IPsec SA is not
Diffie-Hellman Group Transform IDs in IANA Registry started.";
- Internet Key Exchange Version 2 (IKEv2) }
Parameters."; enum on-demand {
} description
"IKE/IPsec configuration is loaded
into IKE implementation. The IPsec policies
are transferred to the NSF's kernel but the
IPsec SAs are not established immediately.
The IKE implementation will negotiate the
IPsec SAs when the NSF's kernel requests it
(i.e. through an ACQUIRE notification).";
}
enum start {
description
"IKE/IPsec configuration is loaded
and transferred to the NSF's kernel, and the
IKEv2 based IPsec SAs are established
immediately without waiting any packet.";
}
}
description
"Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has
started.";
}
typedef auth-protocol-type { typedef pfs-group{
type enumeration { type uint16;
enum ikev2 { description
value 2; "DH groups for IKE and IPsec SA rekey.";
description reference
"IKEv2 authentication protocol. It is the "IANA; Internet Key Exchange V2 (IKEv2) Parameters;
only defined right now. An enum is used for Transform Atribute Types; Transform Type 4 -
further extensibility."; Diffie-Hellman Group Transform IDs.
} Section 3.3.2 in RFC 7296.";
} }
description typedef auth-protocol-type {
"IKE authentication protocol version specified in the type enumeration {
Peer Authorization Database (PAD). It is defined as enum ikev2 {
enumerate to allow new IKE versions in the value 2;
future."; description
reference "IKEv2 authentication protocol. It is the
"RFC 7296."; only defined right now. An enum is used for
further extensibility.";
} }
}
description
"IKE authentication protocol version specified in the
Peer Authorization Database (PAD). It is defined as
enumerate to allow new IKE versions in the
future.";
reference
"RFC 7296.";
}
typedef auth-method-type { typedef auth-method-type {
type enumeration { type enumeration {
enum pre-shared { enum pre-shared {
description description
"Select pre-shared key as the "Select pre-shared key as the
authentication method."; authentication method.";
reference reference
"RFC 7296."; "RFC 7296.";
} }
enum eap { enum eap {
description description
"Select EAP as the authentication method."; "Select EAP as the authentication method.";
reference reference
"RFC 7296."; "RFC 7296.";
} }
enum digital-signature { enum digital-signature {
description description
"Select digital signature method."; "Select digital signature method.";
reference reference
"RFC 7296 and RFC 7427."; "RFC 7296 and RFC 7427.";
} }
enum null { enum null {
description description
"Null authentication."; "Null authentication.";
reference reference
"RFC 7619."; "RFC 7619.";
} }
}
} description
description "Peer authentication method specified in the Peer
"Peer authentication method specified in the Peer Authorization Database (PAD).";
Authorization Database (PAD)."; }
}
container ipsec-ike { container ipsec-ike {
description description
"IKE configuration for a NSF. It includes PAD "IKE configuration for a NSF. It includes PAD
parameters, IKE connections information and state parameters, IKE connections information and state
data."; data.";
container pad { container pad {
description
"Configuration of Peer Authorization Database
(PAD). The PAD contains information about IKE
peer (local and remote). Therefore, the Security
Controller also stores authentication
information for this NSF and can include
several entries for the local NSF not only
remote peers. Storing local and remote
information makes possible to specify that this
NSF with identity A will use some particular
authentication with remote NSF with identity B
and what are the authentication mechanisms
allowed to B.";
list pad-entry {
key "name";
ordered-by user;
description
"Peer Authorization Database (PAD) entry. It
is a list of PAD entries ordered by the
I2NSF Controller.";
leaf name {
type string;
description
"PAD unique name to identify this
entry.";
}
choice identity {
mandatory true;
description
"A particular IKE peer will be
identified by one of these identities.
This peer can be a remote peer or local
peer (this NSF).";
reference
"Section 4.4.3.1 in RFC 4301.";
case ipv4-address{
leaf ipv4-address {
type inet:ipv4-address;
description
"Specifies the identity as a
single four (4) octet.";
}
}
case ipv6-address{
leaf ipv6-address {
type inet:ipv6-address;
description
"Specifies the identity as a
single sixteen (16) octet IPv6
address. An example is
2001:DB8::8:800:200C:417A.";
}
}
case fqdn-string {
leaf fqdn-string {
type inet:domain-name;
description description
"Configuration of Peer Authorization Database "Specifies the identity as a
(PAD). The PAD contains information about IKE Fully-QualifiedDomain Name
peer (local and remote). Therefore, the Security (FQDN) string. An example is:
Controller also stores authentication example.com. The string MUST
information for this NSF and can include NOT contain any terminators
several entries for the local NSF not only (e.g., NULL, CR, etc.).";
remote peers. Storing local and remote }
information makes possible to specify that this }
NSF with identity A will use some particular case rfc822-address-string {
authentication with remote NSF with identity B leaf rfc822-address-string {
and what are the authentication mechanisms type string;
allowed to B."; description
list pad-entry { "Specifies the identity as a
key "name"; fully-qualified RFC5322 email
ordered-by user; address string. An example is,
description jsmith@example.com. The string
"Peer Authorization Database (PAD) entry. It MUST NOT contain any
is a list of PAD entries ordered by the terminators e.g., NULL, CR,
I2NSF Controller."; etc.).";
leaf name { reference
type string; "RFC 5322.";
description }
"PAD unique name to identify this }
entry."; case dnx509 {
} leaf dnx509 {
choice identity { type string;
mandatory true; description
description "Specifies the identity as a
"A particular IKE peer will be ASN.1 X.500 Distinguished
identified by one of these identities. Name. An example is
This peer can be a remote peer or local C=US,O=Example
peer (this NSF)."; Organisation,CN=John Smith.";
reference reference
"Section 4.4.3.1 in RFC 4301."; "RFC 2247.";
case ipv4-address{ }
leaf ipv4-address { }
type inet:ipv4-address; case gnx509 {
description leaf gnx509 {
"Specifies the identity as a type string;
single four (4) octet."; description
} "ASN.1 X.509 GeneralName. RFC
} 5280.";
case ipv6-address{ }
leaf ipv6-address { }
type inet:ipv6-address; case id-key {
description leaf id-key {
"Specifies the identity as a type string;
single sixteen (16) octet IPv6 description
address. An example is "Opaque octet stream that may be
2001:DB8:0:0:8:800:200C:417A."; used to pass vendor-specific
} information for proprietary
} types of identification.";
case fqdn-string { reference
leaf fqdn-string { "Section 3.5 in RFC 7296.";
type inet:domain-name; }
description }
"Specifies the identity as a case id-null {
Fully-QualifiedDomain Name leaf id-null {
(FQDN) string. An example is: type empty;
example.com. The string MUST description
NOT contain any terminators "ID_NULL identification used
(e.g., NULL, CR, etc.)."; when IKE identification payload
} is not used." ;
} reference
case rfc822-address-string { "RFC 7619.";
leaf rfc822-address-string { }
type string; }
description }
"Specifies the identity as a
fully-qualified RFC822 email
address string. An example is,
jsmith@example.com. The string
MUST NOT contain any
terminators e.g., NULL, CR,
etc.).";
reference
"RFC 822.";
}
}
case dnx509 {
leaf dnx509 {
type string;
description
"Specifies the identity as a
ASN.1 X.500 Distinguished
Name. An example is
C=US,O=Example
Organisation,CN=John Smith.";
reference
"RFC 2247.";
}
}
case gnx509 {
leaf gnx509 {
type string;
description
"ASN.1 X.509 GeneralName. RFC
5280.";
}
}
case id-key {
leaf id-key {
type string;
description
"Opaque octet stream that may be
used to pass vendor-specific
information for proprietary
types of identification.";
reference
"Section 3.5 in RFC 7296.";
}
}
case id-null {
leaf id-null {
type empty;
description
"ID_NULL identification used
when IKE identification payload
is not used." ;
reference
"RFC 7619.";
}
}
}
leaf auth-protocol {
type auth-protocol-type;
default ikev2;
description
"Only IKEv2 is supported right now but
other authentication protocols may be
supported in the future.";
}
container peer-authentication {
description
"This container allows the Security
Controller to configure the
authentication method (pre-shared key,
eap, digitial-signature, null) that
will use a particular peer and the
credentials, which will depend on the
selected authentication method.";
leaf auth-method {
type auth-method-type;
default pre-shared;
description
"Type of authentication method
(pre-shared, eap, digital signature,
null).";
reference
"Section 2.15 in RFC 7296.";
}
container eap-method {
when "../auth-method = 'eap'";
leaf eap-type {
type uint8;
mandatory true;
description
"EAP method type. This
information provides the
particular EAP method to be
used. Depending on the EAP
method, pre-shared keys or
certificates may be used.";
}
description
"EAP method description used when
authentication method is 'eap'.";
reference
"Section 2.16 in RFC 7296.";
}
container pre-shared {
when
"../auth-method[.='pre-shared' or
.='eap']";
leaf secret {
nacm:default-deny-all;
type yang:hex-string;
mandatory true;
description
"Pre-shared secret value. The
NSF has to prevent read access
to this value for security
reasons.";
}
description
"Shared secret value for PSK or
EAP method authentication based on
PSK.";
}
container digital-signature {
when
"../auth-method[.='digital-signature'
or .='eap']";
leaf ds-algorithm {
type uint8;
default 1;
description
"The digital signature
algorithm is specified with a
value extracted from the IANA
Registry. Depending on the
algorithm, the following leafs
must contain information. For
example if digital signature
involves a certificate then leaf
'cert-data' and 'private-key'
will contain this information.";
reference
"IKEv2 Authentication Method -
IANA Registry - Internet Key
Exchange Version 2 (IKEv2)
Parameters.";
}
choice public-key { leaf auth-protocol {
mandatory true; type auth-protocol-type;
leaf raw-public-key { default ikev2;
type binary; description
description "Only IKEv2 is supported right now but
"A binary that contains the other authentication protocols may be
value of the public key. The supported in the future.";
interpretation of the content
is defined by the digital
signature algorithm. For
example, an RSA key is
represented as RSAPublicKey as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented
using the 'publicKey'
described in RFC 5915.";
reference
"RFC XXXX: YANG Data Types and
Groupings for Cryptography.";
}
leaf cert-data { }
type ct:x509; container peer-authentication {
description description
"X.509 certificate data - "This container allows the Security
PEM4. If raw-public-key Controller to configure the
is defined this leaf is authentication method (pre-shared key,
empty."; eap, digitial-signature, null) that
reference will use a particular peer and the
"RFC XXXX: YANG Data Types and credentials, which will depend on the
Groupings for Cryptography."; selected authentication method.";
}
description leaf auth-method {
"If the I2NSF Controller type auth-method-type;
knows that the NSF default pre-shared;
already owns a private key description
associated to this public key "Type of authentication method
(the NSF generated the pair (pre-shared, eap, digital signature,
public key/private key out of null).";
band), it will only configure reference
one of the leaf of this "Section 2.15 in RFC 7296.";
choice but not the leaf }
private-key. The NSF, based on container eap-method {
the public key value, can know when "../auth-method = 'eap'";
the private key to be used."; leaf eap-type {
} type uint8;
leaf private-key { mandatory true;
nacm:default-deny-all; description
type binary; "EAP method type. This
description information provides the
"A binary that contains the particular EAP method to be
value of the private key. The used. Depending on the EAP
interpretation of the content method, pre-shared keys or
is defined by the digital certificates may be used.";
signature algorithm. For }
example, an RSA key is description
represented as RSAPrivateKey as "EAP method description used when
defined in RFC 8017, and an authentication method is 'eap'.";
Elliptic Curve Cryptography reference
(ECC) key is represented as "Section 2.16 in RFC 7296.";
ECPrivateKey as defined in RFC }
5915. This value is set container pre-shared {
if public-key is defined and when
I2NSF controller is in charge "../auth-method[.='pre-shared' or
of configuring the .='eap']";
private-key. Otherwise, it is leaf secret {
not set and the value is nacm:default-deny-all;
kept in secret."; type yang:hex-string;
reference mandatory true;
"RFC XXXX: YANG Data Types and description
Groupings for Cryptography."; "Pre-shared secret value. The
} NSF has to prevent read access
leaf-list ca-data { to this value for security
type ct:x509; reasons.";
description }
"List of trusted Certification description
Authorities (CA) certificates "Shared secret value for PSK or
encoded using ASN.1 EAP method authentication based on
distinguished encoding rules PSK.";
(DER). If it is not defined }
the default value is empty."; container digital-signature {
reference when
"RFC XXXX: YANG Data Types and "../auth-method[.='digital-signature'
Groupings for Cryptography."; or .='eap']";
} leaf ds-algorithm {
leaf crl-data { type uint8;
type ct:crl; default 1;
description description
"A CertificateList structure, as "The digital signature
specified in RFC 5280, algorithm is specified with a
encoded using ASN.1 value extracted from the IANA
distinguished encoding rules Registry. Default is RSA Digital
(DER),as specified in ITU-T Signature. Depending on the
X.690. If it is not defined algorithm, the following leafs
the default value is empty."; MUST contain information. For
reference example if digital signature
"RFC XXXX: YANG Data Types and involves a certificate then leaf
Groupings for Cryptography."; 'cert-data' and 'private-key'
} will contain this information.";
leaf crl-uri { reference
type inet:uri; "IANA Registry; Internet Key
description Exchange Version 2 (IKEv2);
"X.509 CRL certificate URI. Parameters; IKEv2 Authentication Method.";
}
If it is not defined choice public-key {
the default value is empty."; mandatory true;
} leaf raw-public-key {
leaf oscp-uri { type binary;
type inet:uri; description
description "A binary that contains the
"OCSP URI. value of the public key. The
If it is not defined interpretation of the content
the default value is empty."; is defined by the digital
} signature algorithm. For
description example, an RSA key is
"Digital Signature container."; represented as RSAPublicKey as
defined in RFC 8017, and an
Elliptic Curve Cryptography
(ECC) key is represented
using the 'publicKey'
described in RFC 5915.";
}
} /*container digital-signature*/ leaf cert-data {
} /*container peer-authentication*/ type binary;
description
"X.509 certificate data -
PEM4. If raw-public-key
is defined this leaf is
empty.";
} }
}
list conn-entry {
key "name";
description description
"IKE peer connection information. This list "If the I2NSF Controller
contains the IKE connection for this peer knows that the NSF
with other peers. This will be translated in already owns a private key
real time by IKE Security Associations associated to this public key
established with these nodes."; (the NSF generated the pair
leaf name { public key/private key out of
type string; band), it will only configure
description one of the leaf of this
"Identifier for this connection choice but not the leaf
entry."; private-key. The NSF, based on
} the public key value, can know
leaf autostartup { the private key to be used.";
type autostartup-type; }
default add; leaf private-key {
description nacm:default-deny-all;
"By-default: Only add configuration type binary;
without starting the security description
association."; "A binary that contains the
} value of the private key. The
leaf initial-contact { interpretation of the content
type boolean; is defined by the digital
default false; signature algorithm. For
description example, an RSA key is
"The goal of this value is to deactivate the represented as RSAPrivateKey as
usage of INITIAL_CONTACT notification defined in RFC 8017, and an
(true). If this flag remains to false it Elliptic Curve Cryptography
means the usage of the INITIAL_CONTACT (ECC) key is represented as
notification will depend on the IKEv2 ECPrivateKey as defined in RFC
implementation."; 5915. This value is set
} if public-key is defined and
leaf version { I2NSF controller is in charge
type auth-protocol-type; of configuring the
default ikev2; private-key. Otherwise, it is
description not set and the value is
"IKE version. Only version 2 is supported kept in secret.";
so far."; }
} leaf-list ca-data {
leaf fragmentation { type binary;
type boolean; description
default false; "List of trusted Certification
description Authorities (CA) certificates
"Whether or not to enable IKE encoded using ASN.1
fragmentation as per RFC 7383 (true or distinguished encoding rules
false)."; (DER). If it is not defined
reference the default value is empty.";
"RFC 7383."; }
} leaf crl-data {
container ike-sa-lifetime-soft { type binary;
description description
"IKE SA lifetime soft. Two lifetime values "A CertificateList structure, as
can be configured: either rekey time of the specified in RFC 5280,
IKE SA or reauth time of the IKE SA. When encoded using ASN.1
the rekey lifetime expires a rekey of the distinguished encoding rules
IKE SA starts. When reauth lifetime (DER),as specified in ITU-T
expires a IKE SA reauthentication starts."; X.690. If it is not defined
leaf rekey-time { the default value is empty.";
type uint32; }
default 0; leaf crl-uri {
description type inet:uri;
"Time in seconds between each IKE SA description
rekey.The value 0 means infinite."; "X.509 CRL certificate URI.
} If it is not defined
leaf reauth-time { the default value is empty.";
type uint32; }
default 0; leaf oscp-uri {
description type inet:uri;
"Time in seconds between each IKE SA description
reauthentication. The value 0 means "OCSP URI.
infinite."; If it is not defined
} the default value is empty.";
reference }
"Section 2.8 in RFC 7296."; description
} "Digital Signature container.";
container ike-sa-lifetime-hard { } /*container digital-signature*/
description } /*container peer-authentication*/
"Hard IKE SA lifetime. When this }
time is reached the IKE SA is removed."; }
leaf over-time {
type uint32;
default 0;
description
"Time in seconds before the IKE SA is
removed. The value 0 means infinite.";
}
reference
"RFC 7296.";
}
leaf-list authalg {
type nsfikec:integrity-algorithm-type;
default 12;
ordered-by user;
description
"Authentication algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority.";
}
list encalg {
key id;
min-elements 1;
ordered-by user;
leaf id {
type uint8;
description
"The index of the list with the
different encryption algorithms and its
key-length (if required). E.g. AES-CBC,
128 bits";
}
leaf algorithm-type {
type nsfikec:encryption-algorithm-type;
default 12;
description
"Default value 12 (ENCR_AES_CBC)";
}
leaf key-length {
type uint16;
default 128;
description
"By default key length is 128 bits";
}
description
"Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority.";
}
leaf dh-group {
type pfs-group;
default 14;
description
"Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange.";
}
leaf half-open-ike-sa-timer {
type uint32;
default 0;
description
"Set the half-open IKE SA timeout
duration.";
reference
"Section 2 in RFC 7296.";
}
leaf half-open-ike-sa-cookie-threshold {
type uint32;
default 0;
description
"Number of half-open IKE SAs that activate
the cookie mechanism." ;
reference
"Section 2.6 in RFC 7296.";
}
container local {
leaf local-pad-entry-name {
type string;
mandatory true;
description
"Local peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular local
peer is stored. It MUST match a
pad-entry-name.";
}
description
"Local peer authentication information.";
}
container remote {
leaf remote-pad-entry-name {
type string;
mandatory true;
description
"Remote peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular
remote peer is stored. It MUST match a
pad-entry-name.";
}
description
"Remote peer authentication information.";
}
container encapsulation-type
{
uses nsfikec:encap;
description
"This container carries configuration
information about the source and destination
ports of encapsulation that IKE should use
and the type of encapsulation that
should use when NAT traversal is required.
However, this is just a best effort since
the IKE implementation may need to use a
different encapsulation as
described in RFC 8229.";
reference
"RFC 8229.";
}
container spd {
description
"Configuration of the Security Policy
Database (SPD). This main information is
placed in the grouping
ipsec-policy-grouping.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SPD entry unique name to identify
the IPsec policy.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of a IPsec policy.";
uses nsfikec:ipsec-policy-grouping;
}
description
"List of entries which will constitute
the representation of the SPD. Since we
have IKE in this case, it is only
required to send a IPsec policy from
this NSF where 'local' is this NSF and
'remote' the other NSF. The IKE
implementation will install IPsec
policies in the NSF's kernel in both
directions (inbound and outbound) and
their corresponding IPsec SAs based on
the information in this SPD entry.";
}
reference
"Section 2.9 in RFC 7296.";
}
container child-sa-info {
leaf-list pfs-groups {
type pfs-group;
default 0;
ordered-by user;
description
"If non-zero, it is required perfect
forward secrecy when requesting new
IPsec SA. The non-zero value is
the required group number. This list is
ordered following from the higher
priority to lower priority. First node
of the list will be the algorithm
with higher priority.";
}
container child-sa-lifetime-soft {
description
"Soft IPsec SA lifetime soft.
After the lifetime the action is
defined in this container
in the leaf action.";
uses nsfikec:lifetime;
leaf action {
type nsfikec:lifetime-action;
default replace;
description
"When the lifetime of an IPsec SA
expires an action needs to be
performed over the IPsec SA that
reached the lifetime. There are
three possible options:
terminate-clear, terminate-hold and
replace.";
reference
"Section 4.5 in RFC 4301 and Section 2.8
in RFC 7296.";
}
}
container child-sa-lifetime-hard {
description
"IPsec SA lifetime hard. The action will
be to terminate the IPsec SA.";
uses nsfikec:lifetime;
reference
"Section 2.8 in RFC 7296.";
}
description
"Specific information for IPsec SAs
SAs. It includes PFS group and IPsec SAs
rekey lifetimes.";
}
container state {
config false;
leaf initiator {
type boolean;
description
"It is acting as initiator for this
connection.";
}
leaf initiator-ikesa-spi {
type ike-spi;
description
"Initiator's IKE SA SPI.";
}
leaf responder-ikesa-spi {
type ike-spi;
description
"Responder's IKE SA SPI.";
}
leaf nat-local {
type boolean;
description
"True, if local endpoint is behind a
NAT.";
}
leaf nat-remote {
type boolean;
description
"True, if remote endpoint is behind
a NAT.";
}
container encapsulation-type list conn-entry {
{ key "name";
uses nsfikec:encap; description
description "IKE peer connection information. This list
"This container provides information contains the IKE connection for this peer
about the source and destination with other peers. This will be translated in
ports of encapsulation that IKE is real time by IKE Security Associations
using, and the type of encapsulation established with these nodes.";
when NAT traversal is required."; leaf name {
reference type string;
"RFC 8229."; description
} "Identifier for this connection
leaf established { entry.";
type uint64; }
description leaf autostartup {
"Seconds since this IKE SA has been type autostartup-type;
established."; default add;
} description
leaf current-rekey-time { "By-default: Only add configuration
type uint64; without starting the security
description association.";
"Seconds before IKE SA must be rekeyed."; }
} leaf initial-contact {
leaf current-reauth-time { type boolean;
type uint64; default false;
description description
"Seconds before IKE SA must be "The goal of this value is to deactivate the
re-authenticated."; usage of INITIAL_CONTACT notification
} (true). If this flag remains to false it
description means the usage of the INITIAL_CONTACT
"IKE state data for a particular notification will depend on the IKEv2
connection."; implementation.";
} /* ike-sa-state */ }
} /* ike-conn-entries */ leaf version {
type auth-protocol-type;
default ikev2;
description
"IKE version. Only version 2 is supported
so far.";
}
leaf fragmentation {
type boolean;
default false;
description
"Whether or not to enable IKE
fragmentation as per RFC 7383 (true or
false).";
reference
"RFC 7383.";
}
container ike-sa-lifetime-soft {
description
"IKE SA lifetime soft. Two lifetime values
can be configured: either rekey time of the
IKE SA or reauth time of the IKE SA. When
the rekey lifetime expires a rekey of the
IKE SA starts. When reauth lifetime
expires a IKE SA reauthentication starts.";
leaf rekey-time {
type uint32;
units "seconds";
default 0;
description
"Time in seconds between each IKE SA
rekey.The value 0 means infinite.";
}
leaf reauth-time {
type uint32;
units "seconds";
default 0;
description
"Time in seconds between each IKE SA
reauthentication. The value 0 means
infinite.";
}
reference
"Section 2.8 in RFC 7296.";
}
container ike-sa-lifetime-hard {
description
"Hard IKE SA lifetime. When this
time is reached the IKE SA is removed.";
leaf over-time {
type uint32;
units "seconds";
default 0;
description
"Time in seconds before the IKE SA is
removed. The value 0 means infinite.";
}
reference
"RFC 7296.";
}
leaf-list authalg {
type nsfikec:integrity-algorithm-type;
default 12;
ordered-by user;
description
"Authentication algorithm for establishing
the IKE SA. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority.";
}
list encalg {
key id;
min-elements 1;
ordered-by user;
leaf id {
type uint8;
description
"The index of the list with the
different encryption algorithms and its
key-length (if required). E.g. AES-CBC,
128 bits";
}
leaf algorithm-type {
type nsfikec:encryption-algorithm-type;
default 12;
description
"Default value 12 (ENCR_AES_CBC)";
}
leaf key-length {
type uint16;
default 128;
description
"By default key length is 128 bits";
}
description
"Encryption or AEAD algorithm for the IKE
SAs. This list is ordered following
from the higher priority to lower priority.
First node of the list will be the algorithm
with higher priority.";
}
leaf dh-group {
type pfs-group;
default 14;
description
"Group number for Diffie-Hellman
Exponentiation used during IKE_SA_INIT
for the IKE SA key exchange.";
}
leaf half-open-ike-sa-timer {
type uint32;
default 0;
description
"Set the half-open IKE SA timeout
duration.";
reference
"Section 2 in RFC 7296.";
}
leaf half-open-ike-sa-cookie-threshold {
type uint32;
default 0;
description
"Number of half-open IKE SAs that activate
the cookie mechanism." ;
reference
"Section 2.6 in RFC 7296.";
}
container local {
leaf local-pad-entry-name {
type string;
mandatory true;
description
"Local peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular local
peer is stored. It MUST match a
pad-entry-name.";
}
description
"Local peer authentication information.";
}
container remote {
leaf remote-pad-entry-name {
type string;
mandatory true;
description
"Remote peer authentication information.
This node points to a specific entry in
the PAD where the authorization
information about this particular
remote peer is stored. It MUST match a
pad-entry-name.";
}
description
"Remote peer authentication information.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container carries configuration
information about the source and destination
ports of encapsulation that IKE should use
and the type of encapsulation that
should use when NAT traversal is required.
However, this is just a best effort since
the IKE implementation may need to use a
different encapsulation as
described in RFC 8229.";
reference
"RFC 8229.";
}
container spd {
description
"Configuration of the Security Policy
Database (SPD). This main information is
placed in the grouping
ipsec-policy-grouping.";
list spd-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SPD entry unique name to identify
the IPsec policy.";
}
container ipsec-policy-config {
description
"This container carries the
configuration of a IPsec policy.";
uses nsfikec:ipsec-policy-grouping;
}
description
"List of entries which will constitute
the representation of the SPD. Since we
have IKE in this case, it is only
required to send a IPsec policy from
this NSF where 'local' is this NSF and
'remote' the other NSF. The IKE
implementation will install IPsec
policies in the NSF's kernel in both
directions (inbound and outbound) and
their corresponding IPsec SAs based on
the information in this SPD entry.";
}
reference
"Section 2.9 in RFC 7296.";
container number-ike-sas { }
config false; container child-sa-info {
leaf total { leaf-list pfs-groups {
type uint64; type pfs-group;
description default 0;
"Total number of active IKE SAs."; ordered-by user;
} description
leaf half-open { "If non-zero, perfect forward secrecy
type uint64; is required when requesting new
description IPsec SA. The non-zero value is
"Number of half-open active IKE SAs."; the required group number. This list is
} ordered following from the higher
leaf half-open-cookies { priority to lower priority. First node
type uint64; of the list will be the algorithm
description with higher priority.";
"Number of half open active IKE SAs with }
cookie activated."; container child-sa-lifetime-soft {
} description
description "Soft IPsec SA lifetime soft.
"General information about the IKE SAs. In After the lifetime the action is
particular, it provides the current number of defined in this container
IKE SAs."; in the leaf action.";
} uses nsfikec:lifetime;
} /* container ipsec-ike */ leaf action {
} type nsfikec:lifetime-action;
default replace;
description
"When the lifetime of an IPsec SA
expires an action needs to be
performed over the IPsec SA that
reached the lifetime. There are
three possible options:
terminate-clear, terminate-hold and
replace.";
reference
"Section 4.5 in RFC 4301 and Section 2.8
in RFC 7296.";
}
}
container child-sa-lifetime-hard {
description
"IPsec SA lifetime hard. The action will
be to terminate the IPsec SA.";
uses nsfikec:lifetime;
reference
"Section 2.8 in RFC 7296.";
}
description
"Specific information for IPsec SAs
SAs. It includes PFS group and IPsec SAs
rekey lifetimes.";
}
container state {
config false;
leaf initiator {
type boolean;
description
"It is acting as initiator for this
connection.";
}
leaf initiator-ikesa-spi {
type ike-spi;
description
"Initiator's IKE SA SPI.";
}
leaf responder-ikesa-spi {
type ike-spi;
description
"Responder's IKE SA SPI.";
}
leaf nat-local {
type boolean;
description
"True, if local endpoint is behind a
NAT.";
}
leaf nat-remote {
type boolean;
description
"True, if remote endpoint is behind
a NAT.";
}
container encapsulation-type {
uses nsfikec:encap;
description
"This container provides information
about the source and destination
ports of encapsulation that IKE is
using, and the type of encapsulation
when NAT traversal is required.";
reference
"RFC 8229.";
}
leaf established {
type uint64;
description
"Seconds since this IKE SA has been
established.";
}
leaf current-rekey-time {
type uint64;
units "seconds";
description
"Seconds before IKE SA MUST be rekeyed.";
}
leaf current-reauth-time {
type uint64;
units "seconds";
description
"Seconds before IKE SA MUST be
re-authenticated.";
}
description
"IKE state data for a particular
connection.";
} /* ike-sa-state */
} /* ike-conn-entries */
container number-ike-sas {
config false;
leaf total {
type uint64;
description
"Total number of active IKE SAs.";
}
leaf half-open {
type uint64;
description
"Number of half-open active IKE SAs.";
}
leaf half-open-cookies {
type uint64;
description
"Number of half open active IKE SAs with
cookie activated.";
}
description
"General information about the IKE SAs. In
particular, it provides the current number of
IKE SAs.";
}
} /* container ipsec-ike */
}
<CODE ENDS> <CODE ENDS>
Appendix C. YANG model for IKE-less case Appendix C. YANG model for IKE-less case
This Appendix is Normative. This Appendix is Normative.
This YANG module has normative references to [RFC4301], [RFC6991], This YANG module has normative references to [RFC4301], [RFC6991],
[RFC8174] and [RFC8341]. [RFC8174] and [RFC8341].
<CODE BEGINS> file "ietf-i2nsf-ikeless@2020-10-22.yang" <CODE BEGINS> file "ietf-i2nsf-ikeless@2020-10-30.yang"
module ietf-i2nsf-ikeless {
yang-version 1.1; module ietf-i2nsf-ikeless {
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless";
prefix "nsfikels"; prefix "nsfikels";
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
} }
import ietf-i2nsf-ikec {
prefix nsfikec;
reference
"Common Data model for SDN-based IPsec
configuration.";
}
import ietf-netconf-acm { import ietf-i2nsf-ikec {
prefix nacm; prefix nsfikec;
reference reference
"RFC 8341: Network Configuration Access Control "RFC XXXX: Software-Defined Networking
Model."; (SDN)-based IPsec Flow Protection.";
} }
organization "IETF I2NSF Working Group"; import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control
Model.";
}
contact organization "IETF I2NSF Working Group";
"WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Rafael Marin-Lopez contact
<mailto:rafa@um.es> "WG Web: <https://datatracker.ietf.org/wg/i2nsf/>
WG List: <mailto:i2nsf@ietf.org>
Author: Gabriel Lopez-Millan Author: Rafael Marin-Lopez
<mailto:gabilm@um.es> <mailto:rafa@um.es>
Author: Fernando Pereniguez-Garcia Author: Gabriel Lopez-Millan
<mailto:fernando.pereniguez@cud.upct.es> <mailto:gabilm@um.es>
";
description Author: Fernando Pereniguez-Garcia
"Data model for IKE-less case in the SDN-base IPsec flow <mailto:fernando.pereniguez@cud.upct.es>
protection service. ";
Copyright (c) 2020 IETF Trust and the persons description
identified as authors of the code. All rights reserved. "Data model for IKE-less case in the SDN-base IPsec flow
Redistribution and use in source and binary forms, with protection service.
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;; Copyright (c) 2020 IETF Trust and the persons
see the RFC itself for full legal notices. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', This version of this YANG module is part of RFC XXXX;;
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', see the RFC itself for full legal notices.
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in BCP 14
(RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
revision "2020-10-22" { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description "Initial version."; 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
reference "RFC XXXX: Software-Defined Networking 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
(SDN)-based IPsec Flow Protection."; document are to be interpreted as described in BCP 14
} (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here.";
feature ikeless-notification { revision "2020-10-30" {
description description "Initial version.";
"This feature indicates that the server supports reference
generating notifications in the ikeless module. "RFC XXXX: Software-Defined Networking
(SDN)-based IPsec Flow Protection.";
}
To ensure broader applicability of this module, feature ikeless-notification {
the notifications are marked as a feature. description
For the implementation of ikeless case, "This feature indicates that the server supports
the NSF is expected to implement this generating notifications in the ikeless module.
feature.";
}
container ipsec-ikeless { To ensure broader applicability of this module,
description the notifications are marked as a feature.
"Container for configuration of the IKE-less For the implementation of ikeless case,
case. The container contains two additional the NSF is expected to implement this
containers: 'spd' and 'sad'. The first allows the feature.";
I2NSF Controller to configure IPsec policies in }
the Security Policy Database SPD, and the second container ipsec-ikeless {
allows to configure IPsec Security Associations description
(IPsec SAs) in the Security Association Database "Container for configuration of the IKE-less
(SAD)."; case. The container contains two additional
reference "RFC 4301."; containers: 'spd' and 'sad'. The first allows the
container spd { I2NSF Controller to configure IPsec policies in
description the Security Policy Database SPD, and the second
"Configuration of the Security Policy Database allows to configure IPsec Security Associations
(SPD.)"; (IPsec SAs) in the Security Association Database
reference "Section 4.4.1.2 in RFC 4301."; (SAD).";
reference "RFC 4301.";
list spd-entry { container spd {
key "name"; description
ordered-by user; "Configuration of the Security Policy Database
leaf name { (SPD.)";
type string; reference "Section 4.4.1.2 in RFC 4301.";
description
"SPD entry unique name to identify this
entry.";
} list spd-entry {
leaf direction { key "name";
type nsfikec:ipsec-traffic-direction; ordered-by user;
mandatory true; leaf name {
description type string;
"Inbound traffic or outbound description
traffic. In the IKE-less case the "SPD entry unique name to identify this
I2NSF Controller needs to entry.";
specify the policy direction to be }
applied in the NSF. In the IKE case leaf direction {
this direction does not need to be type nsfikec:ipsec-traffic-direction;
specified since IKE mandatory true;
will determine the direction that description
IPsec policy will require."; "Inbound traffic or outbound
} traffic. In the IKE-less case the
leaf reqid { I2NSF Controller needs to
type uint64; specify the policy direction to be
default 0; applied in the NSF. In the IKE case
description this direction does not need to be
"This value allows to link this specified since IKE
IPsec policy with IPsec SAs with the will determine the direction that
same reqid. It is only required in IPsec policy will require.";
the IKE-less model since, in the IKE }
case this link is handled internally leaf reqid {
by IKE."; type uint64;
} default 0;
description
"This value allows to link this
IPsec policy with IPsec SAs with the
same reqid. It is only required in
the IKE-less model since, in the IKE
case this link is handled internally
by IKE.";
}
container ipsec-policy-config { container ipsec-policy-config {
description description
"This container carries the "This container carries the
configuration of a IPsec policy."; configuration of a IPsec policy.";
uses nsfikec:ipsec-policy-grouping; uses nsfikec:ipsec-policy-grouping;
} }
description description
"The SPD is represented as a list of SPD "The SPD is represented as a list of SPD
entries, where each SPD entry represents an entries, where each SPD entry represents an
IPsec policy."; IPsec policy.";
} /*list spd-entry*/ } /*list spd-entry*/
} /*container spd*/ } /*container spd*/
container sad { container sad {
description description
"Configuration of the IPsec Security Association "Configuration of the IPsec Security Association
Database (SAD)"; Database (SAD)";
reference "Section 4.4.2.1 in RFC 4301."; reference "Section 4.4.2.1 in RFC 4301.";
list sad-entry {
key "name";
ordered-by user;
leaf name {
type string;
description
"SAD entry unique name to identify this
entry.";
}
leaf reqid {
type uint64;
default 0;
description
"This value allows to link this
IPsec SA with an IPsec policy with
the same reqid.";
}
container ipsec-sa-config { list sad-entry {
description key "name";
"This container allows configuring ordered-by user;
details of an IPsec SA."; leaf name {
leaf spi { type string;
type uint32 { range "0..max"; } description
mandatory true; "SAD entry unique name to identify this
description entry.";
"Security Parameter Index (SPI)'s }
IPsec SA."; leaf reqid {
} type uint64;
leaf ext-seq-num { default 0;
type boolean; description
default true; "This value allows to link this
description IPsec SA with an IPsec policy with
"True if this IPsec SA is using the same reqid.";
extended sequence numbers. True 64 }
bit counter, FALSE 32 bit.";
}
leaf seq-number-counter {
type uint64;
default 0;
description
"A 64-bit counter when this IPsec
SA is using Extended Sequence
Number or 32-bit counter when it
is not. It used to generate the
initial Sequence Number field
in ESP headers.";
}
leaf seq-overflow {
type boolean;
default false;
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore needs to
be rekeyed, or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used this flag MUST BE
false.";
}
leaf anti-replay-window {
type uint32;
default 32;
description
"A 32-bit counter and a bit-map (or
equivalent) used to determine
whether an inbound ESP packet is a
replay. If set to 0 no anti-replay
mechanism is performed.";
}
container traffic-selector {
uses nsfikec:selector-grouping;
description
"The IPsec SA traffic selector.";
}
leaf protocol-parameters {
type nsfikec:ipsec-protocol-parameters;
default esp;
description
"Security protocol of IPsec SA: Only
ESP so far.";
}
leaf mode {
type nsfikec:ipsec-mode;
default transport;
description
"Tunnel or transport mode.";
}
container esp-sa {
when "../protocol-parameters =
'esp'";
description
"In case the IPsec SA is
Encapsulation Security Payload
(ESP), it is required to specify
encryption and integrity
algorithms, and key material.";
container encryption { container ipsec-sa-config {
description description
"Configuration of encryption or "This container allows configuring
AEAD algorithm for IPsec details of an IPsec SA.";
Encapsulation Security Payload leaf spi {
(ESP)."; type uint32 { range "0..max"; }
mandatory true;
description
"Security Parameter Index (SPI)'s
IPsec SA.";
}
leaf ext-seq-num {
type boolean;
default true;
description
"True if this IPsec SA is using
extended sequence numbers. True 64
bit counter, false 32 bit.";
}
leaf seq-number-counter {
type uint64;
default 0;
description
"A 64-bit counter when this IPsec
SA is using Extended Sequence
Number or 32-bit counter when it
is not. It used to generate the
initial Sequence Number field
in ESP headers.";
}
leaf seq-overflow {
type boolean;
default false;
description
"The flag indicating whether
overflow of the sequence number
counter should prevent transmission
of additional packets on the IPsec
SA (false) and, therefore needs to
be rekeyed, or whether rollover is
permitted (true). If Authenticated
Encryption with Associated Data
(AEAD) is used (leaf
esp-algorithms/encryption/algorithm-type)
this flag MUST BE false.";
}
leaf anti-replay-window {
type uint32;
default 32;
description
"A 32-bit counter and a bit-map (or
equivalent) used to determine
whether an inbound ESP packet is a
replay. If set to 0 no anti-replay
mechanism is performed.";
}
container traffic-selector {
uses nsfikec:selector-grouping;
description
"The IPsec SA traffic selector.";
}
leaf protocol-parameters {
type nsfikec:ipsec-protocol-parameters;
default esp;
description
"Security protocol of IPsec SA: Only
ESP so far.";
}
leaf mode {
type nsfikec:ipsec-mode;
default transport;
description
"Tunnel or transport mode.";
}
container esp-sa {
when "../protocol-parameters = 'esp'";
description
"In case the IPsec SA is
Encapsulation Security Payload
(ESP), it is required to specify
encryption and integrity
algorithms, and key material.";
leaf encryption-algorithm { container encryption {
type nsfikec:encryption-algorithm-type; description
default 12; "Configuration of encryption or
description AEAD algorithm for IPsec
"Configuration of ESP Encapsulation Security Payload
encryption. With AEAD (ESP).";
algorithms, the integrity
leaf is not used.";
}
leaf key { leaf encryption-algorithm {
nacm:default-deny-all; type nsfikec:encryption-algorithm-type;
type yang:hex-string; default 12;
description description
"ESP encryption key value. "Configuration of ESP
If this leaf is not defined encryption. With AEAD
the key is not defined algorithms, the integrity-algorithm
(e.g. encryption is NULL). leaf is not used.";
The key length is }
determined by the
length of the key set in
this leaf. By default is
128 bits.";
}
leaf iv {
nacm:default-deny-all;
type yang:hex-string;
description
"ESP encryption IV value. If
this leaf is not defined the
IV is not defined (e.g.
encryption is NULL)";
}
}
container integrity { leaf key {
description nacm:default-deny-all;
"Configuration of integrity for type yang:hex-string;
IPsec Encapsulation Security description
Payload (ESP). This container "ESP encryption key value.
allows to configure integrity If this leaf is not defined
algorithm when no AEAD the key is not defined
algorithms are used, and (e.g. encryption is NULL).
integrity is required."; The key length is
leaf integrity-algorithm { determined by the
type nsfikec:integrity-algorithm-type; length of the key set in
default 12; this leaf. By default is
description 128 bits.";
"Message Authentication Code }
(MAC) algorithm to provide leaf iv {
integrity in ESP nacm:default-deny-all;
(default type yang:hex-string;
AUTH_HMAC_SHA2_256_128). description
With AEAD algorithms, "ESP encryption IV value. If
the integrity leaf is not this leaf is not defined the
used."; IV is not defined (e.g.
} encryption is NULL)";
leaf key { }
nacm:default-deny-all; }
type yang:hex-string;
description
"ESP integrity key value.
If this leaf is not defined
the key is not defined (e.g.
AEAD algorithm is chosen and
integrity algorithm is not
required). The key length is
determined by the length of
the key configured.";
}
}
} /*container esp-sa*/
container sa-lifetime-hard { container integrity {
description description
"IPsec SA hard lifetime. The action "Configuration of integrity for
associated is terminate and IPsec Encapsulation Security
hold."; Payload (ESP). This container
uses nsfikec:lifetime; allows to configure integrity
} algorithm when no AEAD
container sa-lifetime-soft { algorithms are used, and
description integrity is required.";
"IPsec SA soft lifetime."; leaf integrity-algorithm {
uses nsfikec:lifetime; type nsfikec:integrity-algorithm-type;
leaf action { default 12;
type nsfikec:lifetime-action; description
description "Message Authentication Code
"Action lifetime: (MAC) algorithm to provide
terminate-clear, integrity in ESP
terminate-hold or replace."; (default
} AUTH_HMAC_SHA2_256_128).
} With AEAD algorithms,
container tunnel { the integrity leaf is not
when "../mode = 'tunnel'"; used.";
uses nsfikec:tunnel-grouping; }
description leaf key {
"Endpoints of the IPsec tunnel."; nacm:default-deny-all;
} type yang:hex-string;
container encapsulation-type description
{ "ESP integrity key value.
uses nsfikec:encap; If this leaf is not defined
description the key is not defined (e.g.
"This container carries AEAD algorithm is chosen and
configuration information about integrity algorithm is not
the source and destination ports required). The key length is
which will be used for ESP determined by the length of
encapsulation that ESP packets the the key configured.";
type of encapsulation when NAT }
traversal is in place."; }
} } /*container esp-sa*/
} /*ipsec-sa-config*/
container ipsec-sa-state { container sa-lifetime-hard {
config false; description
description "IPsec SA hard lifetime. The action
"Container describing IPsec SA state associated is terminate and
data."; hold.";
container sa-lifetime-current { uses nsfikec:lifetime;
uses nsfikec:lifetime; }
description container sa-lifetime-soft {
"SAD lifetime current."; description
} "IPsec SA soft lifetime.";
container replay-stats { uses nsfikec:lifetime;
description leaf action {
"State data about the anti-replay type nsfikec:lifetime-action;
window."; description
leaf replay-window { "Action lifetime:
type uint64; terminate-clear,
description terminate-hold or replace.";
"Current state of the replay }
window."; }
} container tunnel {
leaf packet-dropped { when "../mode = 'tunnel'";
type uint64; uses nsfikec:tunnel-grouping;
description description
"Packets detected out of the "Endpoints of the IPsec tunnel.";
replay window and dropped }
because they are replay container encapsulation-type {
packets."; uses nsfikec:encap;
} description
leaf failed { "This container carries
type uint32; configuration information about
description the source and destination ports
"Number of packets detected out which will be used for ESP
of the replay window."; encapsulation that ESP packets the
} type of encapsulation when NAT
leaf seq-number-counter { traversal is in place.";
type uint64;
description
"A 64-bit counter when this
IPsec SA is using Extended
Sequence Number or 32-bit
counter when it is not.
Current value of sequence
number.";
}
} /* container replay-stats*/
} /*ipsec-sa-state*/
description }
"List of SAD entries that conforms the SAD."; } /*ipsec-sa-config*/
} /*list sad-entry*/
} /*container sad*/
}/*container ipsec-ikeless*/
/* Notifications */ container ipsec-sa-state {
notification sadb-acquire { config false;
if-feature ikeless-notification; description
description "Container describing IPsec SA state
"An IPsec SA is required. The traffic-selector data.";
container contains information about the IP packet container sa-lifetime-current {
that triggers the acquire notification."; uses nsfikec:lifetime;
leaf ipsec-policy-name { description
type string; "SAD lifetime current.";
mandatory true; }
description container replay-stats {
"It contains the SPD entry name (unique) of description
the IPsec policy that hits the IP packet "State data about the anti-replay
required IPsec SA. It is assumed the window.";
I2NSF Controller will have a copy of the leaf replay-window {
information of this policy so it can type uint64;
extract all the information with this description
unique identifier. The type of IPsec SA is "Current state of the replay
defined in the policy so the Security window.";
Controller can also know the type of IPsec
SA that must be generated.";
}
container traffic-selector {
description
"The IP packet that triggered the acquire
and requires an IPsec SA. Specifically it
will contain the IP source/mask and IP
destination/mask; protocol (udp, tcp,
etc...); and source and destination
ports.";
uses nsfikec:selector-grouping;
} }
} leaf packet-dropped {
type uint64;
description
"Packets detected out of the
replay window and dropped
because they are replay
packets.";
}
leaf failed {
type uint32;
description
"Number of packets detected out
of the replay window.";
}
leaf seq-number-counter {
type uint64;
description
"A 64-bit counter when this
IPsec SA is using Extended
Sequence Number or 32-bit
counter when it is not.
Current value of sequence
number.";
}
} /* container replay-stats*/
notification sadb-expire { } /*ipsec-sa-state*/
if-feature ikeless-notification;
description "An IPsec SA expiration (soft or hard).";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that has expired. It is assumed
the I2NSF Controller will have a copy of the
IPsec SA information (except the cryptographic
material and state data) indexed by this name
(unique identifier) so it can know all the
information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier.";
}
leaf soft-lifetime-expire {
type boolean;
default true;
description
"If this value is true the lifetime expired is
soft. If it is false is hard.";
}
container lifetime-current {
description
"IPsec SA current lifetime. If
soft-lifetime-expired is true this container is
set with the lifetime information about current
soft lifetime.";
uses nsfikec:lifetime;
} description
} "List of SAD entries that conforms the SAD.";
notification sadb-seq-overflow { } /*list sad-entry*/
if-feature ikeless-notification; } /*container sad*/
description "Sequence overflow notification."; }/*container ipsec-ikeless*/
leaf ipsec-sa-name {
type string; /* Notifications */
mandatory true; notification sadb-acquire {
description if-feature ikeless-notification;
"It contains the SAD entry name (unique) of description
the IPsec SA that is about to have sequence "An IPsec SA is required. The traffic-selector
number overflow and rollover is not permitted. container contains information about the IP packet
It is assumed the I2NSF Controller will have that triggers the acquire notification.";
a copy of the IPsec SA information (except the leaf ipsec-policy-name {
cryptographic material and state data) indexed type string;
by this name (unique identifier) so the it can mandatory true;
know all the information (crypto algorithms, description
etc.) about the IPsec SA that has expired in "It contains the SPD entry name (unique) of
order to perform a rekey of the IPsec SA."; the IPsec policy that hits the IP packet
} required IPsec SA. It is assumed the
} I2NSF Controller will have a copy of the
notification sadb-bad-spi { information of this policy so it can
if-feature ikeless-notification; extract all the information with this
description unique identifier. The type of IPsec SA is
"Notify when the NSF receives a packet with an defined in the policy so the Security
incorrect SPI (i.e. not present in the SAD)."; Controller can also know the type of IPsec
leaf spi { SA that MUST be generated.";
type uint32 { range "0..max"; } }
mandatory true; container traffic-selector {
description description
"SPI number contained in the erroneous IPsec "The IP packet that triggered the acquire
packet."; and requires an IPsec SA. Specifically it
} will contain the IP source/mask and IP
} destination/mask; protocol (udp, tcp,
} etc...); and source and destination
ports.";
uses nsfikec:selector-grouping;
}
}
notification sadb-expire {
if-feature ikeless-notification;
description "An IPsec SA expiration (soft or hard).";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that has expired. It is assumed
the I2NSF Controller will have a copy of the
IPsec SA information (except the cryptographic
material and state data) indexed by this name
(unique identifier) so it can know all the
information (crypto algorithms, etc.) about
the IPsec SA that has expired in order to
perform a rekey (soft lifetime) or delete it
(hard lifetime) with this unique identifier.";
}
leaf soft-lifetime-expire {
type boolean;
default true;
description
"If this value is true the lifetime expired is
soft. If it is false is hard.";
}
container lifetime-current {
description
"IPsec SA current lifetime. If
soft-lifetime-expired is true this container is
set with the lifetime information about current
soft lifetime.";
uses nsfikec:lifetime;
}
}
notification sadb-seq-overflow {
if-feature ikeless-notification;
description "Sequence overflow notification.";
leaf ipsec-sa-name {
type string;
mandatory true;
description
"It contains the SAD entry name (unique) of
the IPsec SA that is about to have sequence
number overflow and rollover is not permitted.
It is assumed the I2NSF Controller will have
a copy of the IPsec SA information (except the
cryptographic material and state data) indexed
by this name (unique identifier) so the it can
know all the information (crypto algorithms,
etc.) about the IPsec SA that has expired in
order to perform a rekey of the IPsec SA.";
}
}
notification sadb-bad-spi {
if-feature ikeless-notification;
description
"Notify when the NSF receives a packet with an
incorrect SPI (i.e. not present in the SAD).";
leaf spi {
type uint32 { range "0..max"; }
mandatory true;
description
"SPI number contained in the erroneous IPsec
packet.";
}
}
}
<CODE ENDS> <CODE ENDS>
Appendix D. XML configuration example for IKE case (gateway-to-gateway) Appendix D. XML configuration example for IKE case (gateway-to-gateway)
This example shows a XML configuration file sent by the I2NSF This example shows a XML configuration file sent by the I2NSF
Controller to establish a IPsec Security Association between two NSFs Controller to establish a IPsec Security Association between two NSFs
(see Figure 3) in tunnel mode (gateway-to-gateway) with ESP, (see Figure 3) in tunnel mode (gateway-to-gateway) with ESP,
authentication based on X.509 certificates and applying the IKE case. authentication based on X.509 certificates and applying the IKE case.
skipping to change at page 89, line 34 skipping to change at page 90, line 34
operations from NSF A and NSF B, it proceeds with installing to operations from NSF A and NSF B, it proceeds with installing to
the new outbound IPsec SAs. Even though this procedure may the new outbound IPsec SAs. Even though this procedure may
increase the latency to complete the process, no traffic is sent increase the latency to complete the process, no traffic is sent
over the network until the IPsec SAs are completely operative. over the network until the IPsec SAs are completely operative.
In any case other alternatives MAY be possible to implement step In any case other alternatives MAY be possible to implement step
3. 3.
4. If some of the operations described above fail (e.g. the NSF A 4. If some of the operations described above fail (e.g. the NSF A
reports an error when the I2NSF Controller is trying to install reports an error when the I2NSF Controller is trying to install
the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF the SPD entry, the new inbound or outbound IPsec SAs) the I2NSF
Controller must perform rollback operations by deleting any new Controller MUST perform rollback operations by deleting any new
inbound or outbound SA and SPD entry that had been successfully inbound or outbound SA and SPD entry that had been successfully
installed in any of the NSFs (e.g NSF B) and stop the process. installed in any of the NSFs (e.g NSF B) and stop the process.
Note that the I2NSF Controller may retry several times before Note that the I2NSF Controller may retry several times before
giving up. giving up.
5. Otherwise, if the steps 1 to 3 are successful, the flow between 5. Otherwise, if the steps 1 to 3 are successful, the flow between
NSF A and NSF B is protected by means of the IPsec SAs NSF A and NSF B is protected by means of the IPsec SAs
established by the I2NSF Controller. It is worth mentioning that established by the I2NSF Controller. It is worth mentioning that
the I2NSF Controller associates a lifetime to the new IPsec SAs. the I2NSF Controller associates a lifetime to the new IPsec SAs.
When this lifetime expires, the NSF will send a sadb-expire When this lifetime expires, the NSF will send a sadb-expire
skipping to change at page 90, line 39 skipping to change at page 91, line 39
the outbound IPsec SA to B with SPIa2. At this point the new the outbound IPsec SA to B with SPIa2. At this point the new
IPsec SAs are ready. IPsec SAs are ready.
3. Once the I2NSF Controller receives confirmation from A and B that 3. Once the I2NSF Controller receives confirmation from A and B that
the outbound IPsec SAs have been installed, the I2NSF Controller, the outbound IPsec SAs have been installed, the I2NSF Controller,
in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and
outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1). outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1).
If some of the operations in step 1 fail (e.g. the NSF A reports an If some of the operations in step 1 fail (e.g. the NSF A reports an
error when the I2NSF Controller is trying to install a new inbound error when the I2NSF Controller is trying to install a new inbound
IPsec SA) the I2NSF Controller must perform rollback operations by IPsec SA) the I2NSF Controller MUST perform rollback operations by
removing any new inbound SA that had been successfully installed removing any new inbound SA that had been successfully installed
during step 1. during step 1.
If step 1 is successful but some of the operations in step 2 fails If step 1 is successful but some of the operations in step 2 fails
(e.g. the NSF A reports an error when the I2NSF Controller is trying (e.g. the NSF A reports an error when the I2NSF Controller is trying
to install the new outbound IPsec SA), the I2NSF Controller must to install the new outbound IPsec SA), the I2NSF Controller MUST
perform a rollback operation by deleting any new outbound SA that had perform a rollback operation by deleting any new outbound SA that had
been successfully installed during step 2 and by deleting the inbound been successfully installed during step 2 and by deleting the inbound
SAs created in step 1. SAs created in step 1.
If the steps 1 and 2 are successful but the step 3 fails, the I2NSF If the steps 1 and 2 are successful but the step 3 fails, the I2NSF
Controller will avoid any rollback of the operations carried out in Controller will avoid any rollback of the operations carried out in
step 1 and step 2 since new and valid IPsec SAs were created and are step 1 and step 2 since new and valid IPsec SAs were created and are
functional. The I2NSF Controller may reattempt to remove the old functional. The I2NSF Controller may reattempt to remove the old
inbound and outbound SAs in NSF A and NSF B several times until it inbound and outbound SAs in NSF A and NSF B several times until it
receives a success or it gives up. In the last case, the old IPsec receives a success or it gives up. In the last case, the old IPsec
 End of changes. 134 change blocks. 
2087 lines changed or deleted 2101 lines changed or added

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