--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt 2020-10-30 11:13:25.422248751 -0700 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-12.txt 2020-10-30 11:13:25.598253215 -0700 @@ -1,20 +1,20 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: April 25, 2021 F. Pereniguez-Garcia +Expires: May 3, 2021 F. Pereniguez-Garcia University Defense Center - October 22, 2020 + October 30, 2020 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 This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) controller. It considers two main well- known scenarios in IPsec: (i) gateway-to-gateway and (ii) host-to- host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (SAs) from a I2NSF Controller to one or several flow-based Network Security @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 25, 2021. + This Internet-Draft will expire on May 3, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,35 +76,35 @@ 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 24 8.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 29 - Appendix A. Common YANG model for IKE and IKE-less cases . . . . 31 - Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 46 - Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 65 + Appendix A. Common YANG model for IKE and IKE-less cases . . . . 32 + Appendix B. YANG model for IKE case . . . . . . . . . . . . . . 47 + Appendix C. YANG model for IKE-less case . . . . . . . . . . . . 66 Appendix D. XML configuration example for IKE case (gateway-to- - gateway) . . . . . . . . . . . . . . . . . . . . . . 76 + gateway) . . . . . . . . . . . . . . . . . . . . . . 77 Appendix E. XML configuration example for IKE-less case (host- to-host) . . . . . . . . . . . . . . . . . . . . . . 80 - Appendix F. XML notification examples . . . . . . . . . . . . . 84 + Appendix F. XML notification examples . . . . . . . . . . . . . 85 Appendix G. Operational use cases examples . . . . . . . . . . . 86 G.1. Example of IPsec SA establishment . . . . . . . . . . . . 86 - G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 86 - G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 88 - G.2. Example of the rekeying process in IKE-less case . . . . 90 - G.3. Example of managing NSF state loss in IKE-less case . . . 91 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 + G.1.1. IKE case . . . . . . . . . . . . . . . . . . . . . . 87 + G.1.2. IKE-less case . . . . . . . . . . . . . . . . . . . . 89 + G.2. Example of the rekeying process in IKE-less case . . . . 91 + G.3. Example of managing NSF state loss in IKE-less case . . . 92 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92 1. Introduction Software-Defined Networking (SDN) is an architecture that enables users to directly program, orchestrate, control and manage network resources through software. The SDN paradigm relocates the control of network resources to a centralized entity, namely SDN Controller. SDN controllers configure and manage distributed network resources and provide an abstracted view of the network resources to SDN applications. SDN applications can customize and automate the @@ -189,43 +189,43 @@ the I2NSF Controller and the NSF. Using YANG data modelling language version 1.1 [RFC7950] and based on YANG models defined in [netconf-vpn], [I-D.tran-ipsecme-yang], RFC 4301 [RFC4301] and RFC 7296 [RFC7296], this document defines the required interfaces with a YANG model for configuration and state data for IKE, PAD, SPD and SAD (see Appendix A, Appendix B and Appendix C). The proposed YANG data model conforms to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. Examples of the usage of these models 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, which allows the establishment and management of IPsec security associations from the I2NSF Controller in order to protect specific data flows between two flow-based NSFs implementing IPsec. o To map this architecture to the I2NSF Framework. o To define the interfaces required to manage and monitor the IPsec SAs in the NSF from a I2NSF Controller. YANG data models are defined for configuration and state data for IPsec and IKEv2 - management through the I2NSF NSF-Facing interface. Thus, this I-D - does not define any new protocol. + management through the I2NSF NSF-Facing interface. Thus, this + document does not define any new protocol. 2. Requirements Language 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 RFC - 2119 [RFC2119]. When these words appear in lower case, they have - their natural language meaning. + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 3. Terminology This document uses the terminology described in [RFC8329], [RFC8192], [RFC4301],[RFC7296], [RFC6241], [ITU-T.Y.3300]. The following term is defined in [ITU-T.Y.3300]: o Software-Defined Networking. The following terms are in defined in [RFC8192]: @@ -607,24 +607,24 @@ | +--rw eap-method | | +--rw eap-type uint8 | +--rw pre-shared | | +--rw secret yang:hex-string | +--rw digital-signature | +--rw ds-algorithm? uint8 | +--rw (public-key) | | +--:(raw-public-key) | | | +--rw raw-public-key? binary | | +--:(cert-data) - | | +--rw cert-data? ct:x509 + | | +--rw cert-data? binary | +--rw private-key? binary - | +--rw ca-data* ct:x509 - | +--rw crl-data? ct:crl + | +--rw ca-data* binary + | +--rw crl-data? binary | +--rw crl-uri? inet:uri | +--rw oscp-uri? inet:uri +--rw conn-entry* [name] | +--rw name string | +--rw autostartup? autostartup-type | +--rw initial-contact? boolean | +--rw version? auth-protocol-type | +--rw fragmentation? boolean | +--rw ike-sa-lifetime-soft | | +--rw rekey-time? uint32 @@ -677,21 +677,21 @@ | | | | +--rw encryption* [id] | | | | | +--rw id uint8 | | | | | +--rw algorithm-type? nsfikec:encryption-algorithm-type | | | | | +--rw key-length? uint16 | | | | +--rw tfc-pad? boolean | | | +--rw tunnel | | | +--rw local inet:ip-address | | | +--rw remote inet:ip-address | | | +--rw df-bit? enumeration | | | +--rw bypass-dscp? boolean - | | | +--rw dscp-mapping? yang:hex-string + | | | +--rw dscp-mapping* inet:dscp | | | +--rw ecn? boolean | | +--rw spd-mark | | +--rw mark? uint32 | | +--rw mask? yang:hex-string | +--rw child-sa-info | | +--rw pfs-groups* pfs-group | | +--rw child-sa-lifetime-soft | | | +--rw time? uint32 | | | +--rw bytes? uint32 | | | +--rw packets? uint32 @@ -847,21 +847,21 @@ | | | +--rw encryption* [id] | | | |+--rw id uint8 | | | |+--rw algorithm-type? nsfikec:encryption-algorithm-type | | | |+--rw key-length? uint16 | | | +--rw tfc-pad? boolean | | +--rw tunnel | | +--rw local inet:ip-address | | +--rw remote inet:ip-address | | +--rw df-bit? enumeration | | +--rw bypass-dscp? boolean - | | +--rw dscp-mapping? yang:hex-string + | | +--rw dscp-mapping* inet:dscp | | +--rw ecn? boolean | +--rw spd-mark | +--rw mark? uint32 | +--rw mask? yang:hex-string +--rw sad +--rw sad-entry* [name] +--rw name string +--rw reqid? uint64 +--rw ipsec-sa-config | +--rw spi uint32 @@ -898,21 +898,21 @@ | | +--rw time? uint32 | | +--rw bytes? uint32 | | +--rw packets? uint32 | | +--rw idle? uint32 | | +--rw action? nsfikec:lifetime-action | +--rw tunnel | | +--rw local inet:ip-address | | +--rw remote inet:ip-address | | +--rw df-bit? enumeration | | +--rw bypass-dscp? boolean - | | +--rw dscp-mapping? yang:hex-string + | | +--rw dscp-mapping* inet:dscp | | +--rw ecn? boolean | +--rw encapsulation-type | +--rw espencap? esp-encap | +--rw sport? inet:port-number | +--rw dport? inet:port-number | +--rw oaddr* inet:ip-address +--ro ipsec-sa-state +--ro sa-lifetime-current | +--ro time? uint32 | +--ro bytes? uint32 @@ -1176,28 +1176,61 @@ David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham Bartlett, Sandeep Kampati, Linda Dunbar, Mohit Sethi, Martin Bjorklund, Tom Petch, Christian Hopps, Rob Wilton, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez, Ruben Ricart and Roman Danyliw for their valuable comments. 10. References 10.1. Normative References - [I-D.draft-ietf-netconf-crypto-types] - Watsen, K., "YANG Data Types and Groupings for - Cryptography", draft-ietf-netconf-crypto-types-18 (work in - progress), August 2020. + [IANA-Protocols-Number] + Internet Assigned Numbers Authority (IANA), "Protocol + Numbers", January 2020, . + + [IKEv2-Auth-Method] + Internet Assigned Numbers Authority (IANA), "Internet Key + Exchange Version 2 (IKEv2) Parameters - IKEv2 + Authentication Method", August 2020, + . [IKEv2-Parameters] Internet Assigned Numbers Authority (IANA), "Internet Key - Exchange Version 2 (IKEv2) Parameters", August 2020. + Exchange Version 2 (IKEv2) Parameters", August 2020, + . + + [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, . + + [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, . + + [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, . [ITU-T.X.690] "Recommendation ITU-T X.690", August 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. @@ -1217,20 +1250,24 @@ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key Structure", RFC 5915, DOI 10.17487/RFC5915, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., @@ -1403,42 +1440,39 @@ [strongswan] CESNET, "StrongSwan: the OpenSource IPsec-based VPN Solution", September 2020. Appendix A. Common YANG model for IKE and IKE-less cases This Appendix is Normative. 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 [RFC8229]. - file "ietf-i2nsf-ikec@2020-10-22.yang" + 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 { prefix inet; reference "RFC 6991: Common YANG Data Types"; } - import ietf-yang-types { - prefix yang; - reference "RFC 6991: Common YANG Data Types"; - } - organization "IETF I2NSF Working Group"; contact "WG Web: WG List: Author: Rafael Marin-Lopez Author: Gabriel Lopez-Millan @@ -1464,35 +1499,36 @@ This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2020-10-22" { + revision "2020-10-30" { description "Initial version."; reference "RFC XXXX: Software-Defined Networking (SDN)-based IPsec Flow Protection."; } typedef encryption-algorithm-type { type uint16; description "The encryption algorithm is specified with a 16-bit number extracted from IANA Registry. The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference - "IANA Registry- Transform Type 1 - Encryption + "IANA; Internet Key Exchange V2 (IKEv2) Parameters; + Transform Atribute Types; Transform Type 1 - Encryption Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) and RFC 8247 - Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } typedef integrity-algorithm-type { @@ -1493,25 +1529,25 @@ Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)."; } typedef integrity-algorithm-type { type uint16; description "The integrity algorithm is specified with a 16-bit number extracted from IANA Registry. - The acceptable values MUST follow the requirement levels for encryption algorithms for ESP and IKEv2."; reference - "IANA Registry- Transform Type 3 - Integrity + "IANA; Internet Key Exchange V2 (IKEv2) Parameters; + 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 { @@ -1667,21 +1701,24 @@ } } } default any; description "IPsec protection can be applied to specific IP traffic and layer 4 traffic (TCP, UDP, SCTP, etc.) or ANY protocol in the IP packet payload. We specify the IP protocol number with an uint8 or ANY defining an enumerate with value 256 to - indicate the protocol number."; + indicate the protocol number. NOTE: In case + of IPv6, the protocol in the IP packet payload + is specified in the Next Header field of the IPv6 + packet."; reference "Section 4.4.1.1 in RFC 4301. IANA Registry - Protocol Numbers."; } grouping encap { description "This group of nodes allows to define the type of encapsulation in case NAT traversal is required and port information."; @@ -1713,20 +1750,21 @@ } reference "RFC 3947 and RFC 8229."; } 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; @@ -1740,20 +1778,21 @@ 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 @@ -1767,25 +1805,28 @@ expressed in RFC 4301. For example: 1500 (Start Port Number)-1600 (End Port Number). A port range is used in the Traffic Selector."; leaf start { type inet:port-number; description "Start port number."; } leaf end { type inet:port-number; + must '. >= ../start' { + error-message + "The end port number MUST be equal or greater + than the start port number."; + } description - "End port number. The assigned value must be - equal or greater than the start port number. - To express a single port, set the same value - as start and end."; + "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 { description "The parameters required to define the IP tunnel endpoints when IPsec SA requires tunnel mode. The tunnel is defined by two endpoints: the local IP address and the remote IP address."; @@ -1832,39 +1873,38 @@ leaf bypass-dscp { type boolean; default true; description "If DSCP (Differentiated Services Code Point) values in the inner header have to be used to select one IPsec SA among several that match the traffic selectors for an outbound packet"; reference "Section 4.4.2.1. in RFC 4301."; - } - leaf dscp-mapping { - type yang:hex-string; - default "00:00:00:00:00:00"; + 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 Annex C in RFC 4301."; + "Section 5.1.2 and Appendix C in RFC 4301."; } } grouping selector-grouping { description "This grouping contains the definition of a Traffic Selector, which is used in the IPsec policies and IPsec SAs."; leaf local-subnet { @@ -1980,22 +2020,23 @@ 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."; + (AEAD) is used (leaf + esp-algorithms/encryption/algorithm-type) + 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 { @@ -2021,25 +2062,23 @@ 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."; + the integrity node is not used."; reference "Section 3.2 in RFC 4303."; - } list encryption { key id; ordered-by user; leaf id { type uint8; description "The index of list with the different encryption algorithms and its key-length (if required)."; @@ -2097,87 +2135,81 @@ 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; + type uint32; + default 0; description "Mask used to match XFRM policies and states."; } } } } Appendix B. YANG model for IKE case This Appendix is Normative. This YANG module has normative references to [RFC2247], [RFC5280], [RFC4301], [RFC5280], [RFC5915], [RFC6991], [RFC7296], [RFC7383], - [RFC7427], [RFC7619], [RFC8017], [RFC8174], [RFC8341], [ITU-T.X.690], - [I-D.draft-ietf-netconf-crypto-types] and [IKEv2-Parameters]. + [RFC7427], [RFC7619], [RFC8017], [ITU-T.X.690], [RFC5322], [RFC8174], + [IKEv2-Auth-Method], [IKEv2-Transform-Type-4] and [IKEv2-Parameters]. This YANG module has informative references to [RFC8229]. - file "ietf-i2nsf-ike@2020-10-22.yang" + 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 { prefix yang; reference "RFC 6991: Common YANG Data Types"; } - import ietf-crypto-types { - prefix ct; - reference "RFC XXXX: YANG Data Types and Groupings - for Cryptography."; - } - import ietf-i2nsf-ikec { prefix nsfikec; reference - "Common Data model for SDN-based IPsec - configuration."; + "RFC XXXX: Software-Defined Networking + (SDN)-based IPsec Flow Protection."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; - } organization "IETF I2NSF Working Group"; contact "WG Web: WG List: Author: Rafael Marin-Lopez @@ -2208,25 +2240,25 @@ This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2020-10-22" { + revision "2020-10-30" { description "Initial version."; - reference "RFC XXXX: Software-Defined Networking + reference + "RFC XXXX: Software-Defined Networking (SDN)-based IPsec Flow Protection."; - } typedef ike-spi { type uint64 { range "0..max"; } description "Security Parameter Index (SPI)'s IKE SA."; reference "Section 2.6 in RFC 7296."; } @@ -2242,43 +2274,43 @@ 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 + 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 { type uint16; description "DH groups for IKE and IPsec SA rekey."; reference - "Section 3.3.2 in RFC 7296. Transform Type 4 - - Diffie-Hellman Group Transform IDs in IANA Registry - - Internet Key Exchange Version 2 (IKEv2) - Parameters."; + "IANA; Internet Key Exchange V2 (IKEv2) Parameters; + Transform Atribute Types; Transform Type 4 - + Diffie-Hellman Group Transform IDs. + Section 3.3.2 in RFC 7296."; } - typedef auth-protocol-type { type enumeration { enum ikev2 { value 2; description "IKEv2 authentication protocol. It is the only defined right now. An enum is used for further extensibility."; } } @@ -2375,48 +2406,48 @@ 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:0:0:8:800:200C:417A."; + 2001:DB8::8:800:200C:417A."; } } case fqdn-string { leaf fqdn-string { type inet:domain-name; description "Specifies the identity as a Fully-QualifiedDomain Name (FQDN) string. An example is: example.com. The string MUST NOT contain any terminators (e.g., NULL, CR, etc.)."; } } case rfc822-address-string { leaf rfc822-address-string { type string; description "Specifies the identity as a - fully-qualified RFC822 email + fully-qualified RFC5322 email address string. An example is, jsmith@example.com. The string MUST NOT contain any terminators e.g., NULL, CR, etc.)."; reference - "RFC 822."; + "RFC 5322."; } } 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 @@ -2526,68 +2560,61 @@ 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 + Registry. Default is RSA Digital + Signature. Depending on the algorithm, the following leafs - must contain information. For + 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."; + "IANA Registry; Internet Key + Exchange Version 2 (IKEv2); + Parameters; IKEv2 Authentication Method."; } choice public-key { mandatory true; leaf raw-public-key { type binary; description "A binary that contains the value of the public key. The interpretation of the content is defined by the digital signature algorithm. For example, an RSA key is represented as RSAPublicKey as defined in RFC 8017, and an Elliptic Curve Cryptography (ECC) key is represented using the 'publicKey' described in RFC 5915."; - reference - "RFC XXXX: YANG Data Types and - Groupings for Cryptography."; } leaf cert-data { - type ct:x509; + type binary; description "X.509 certificate data - PEM4. If raw-public-key is defined this leaf is empty."; - reference - "RFC XXXX: YANG Data Types and - Groupings for Cryptography."; } - description "If the I2NSF Controller knows that the NSF already owns a private key associated to this public key (the NSF generated the pair public key/private key out of band), it will only configure one of the leaf of this choice but not the leaf @@ -2610,56 +2637,46 @@ Elliptic Curve Cryptography (ECC) key is represented as ECPrivateKey as defined in RFC 5915. This value is set if public-key is defined and I2NSF controller is in charge of configuring the private-key. Otherwise, it is not set and the value is kept in secret."; - reference - "RFC XXXX: YANG Data Types and - Groupings for Cryptography."; } leaf-list ca-data { - type ct:x509; + type binary; description "List of trusted Certification Authorities (CA) certificates encoded using ASN.1 distinguished encoding rules (DER). If it is not defined the default value is empty."; - reference - "RFC XXXX: YANG Data Types and - Groupings for Cryptography."; } leaf crl-data { - type ct:crl; + type binary; description "A CertificateList structure, as specified in RFC 5280, encoded using ASN.1 distinguished encoding rules (DER),as specified in ITU-T X.690. If it is not defined the default value is empty."; - reference - "RFC XXXX: YANG Data Types and - Groupings for Cryptography."; } leaf crl-uri { type inet:uri; description "X.509 CRL certificate URI. - If it is not defined the default value is empty."; } leaf oscp-uri { type inet:uri; description "OCSP URI. If it is not defined the default value is empty."; } @@ -2724,42 +2740,45 @@ 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; @@ -2855,22 +2871,21 @@ "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 - { + 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 @@ -2907,29 +2922,30 @@ 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 + "If non-zero, perfect forward secrecy + is required 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. @@ -2983,56 +2998,55 @@ 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 - { + 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."; + "Seconds before IKE SA MUST be rekeyed."; } leaf current-reauth-time { type uint64; + units "seconds"; description - "Seconds before IKE SA must be + "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; @@ -3052,48 +3066,47 @@ "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 */ } - Appendix C. YANG model for IKE-less case This Appendix is Normative. This YANG module has normative references to [RFC4301], [RFC6991], [RFC8174] and [RFC8341]. - file "ietf-i2nsf-ikeless@2020-10-22.yang" + file "ietf-i2nsf-ikeless@2020-10-30.yang" module ietf-i2nsf-ikeless { - yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless"; prefix "nsfikels"; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } + import ietf-i2nsf-ikec { prefix nsfikec; reference - "Common Data model for SDN-based IPsec - configuration."; + "RFC XXXX: Software-Defined Networking + (SDN)-based IPsec Flow Protection."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; } organization "IETF I2NSF Working Group"; @@ -3128,23 +3141,24 @@ This version of this YANG module is part of RFC XXXX;; see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision "2020-10-22" { + revision "2020-10-30" { description "Initial version."; - reference "RFC XXXX: Software-Defined Networking + reference + "RFC XXXX: Software-Defined Networking (SDN)-based IPsec Flow Protection."; } feature ikeless-notification { description "This feature indicates that the server supports generating notifications in the ikeless module. To ensure broader applicability of this module, the notifications are marked as a feature. @@ -3252,21 +3266,21 @@ 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."; + 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 @@ -3277,22 +3291,23 @@ 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."; + (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."; @@ -3309,43 +3324,42 @@ "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'"; + 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 { description "Configuration of encryption or AEAD algorithm for IPsec Encapsulation Security Payload (ESP)."; leaf encryption-algorithm { type nsfikec:encryption-algorithm-type; default 12; description "Configuration of ESP encryption. With AEAD - algorithms, the integrity + algorithms, the integrity-algorithm leaf is not used."; } leaf key { nacm:default-deny-all; type yang:hex-string; description "ESP encryption key value. If this leaf is not defined the key is not defined @@ -3423,31 +3437,31 @@ terminate-clear, terminate-hold or replace."; } } container tunnel { when "../mode = 'tunnel'"; uses nsfikec:tunnel-grouping; description "Endpoints of the IPsec tunnel."; } - container encapsulation-type - { + container encapsulation-type { uses nsfikec:encap; description "This container carries configuration information about the source and destination ports which will be used for ESP encapsulation that ESP packets the type of encapsulation when NAT traversal is in place."; + } } /*ipsec-sa-config*/ container ipsec-sa-state { config false; description "Container describing IPsec SA state data."; container sa-lifetime-current { uses nsfikec:lifetime; @@ -3510,21 +3525,21 @@ description "It contains the SPD entry name (unique) of the IPsec policy that hits the IP packet required IPsec SA. It is assumed the I2NSF Controller will have a copy of the information of this policy so it can extract all the information with this unique identifier. The type of IPsec SA is defined in the policy so the Security Controller can also know the type of IPsec - SA that must be generated."; + 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; @@ -4184,21 +4194,21 @@ operations from NSF A and NSF B, it proceeds with installing to the new outbound IPsec SAs. Even though this procedure may increase the latency to complete the process, no traffic is sent over the network until the IPsec SAs are completely operative. In any case other alternatives MAY be possible to implement step 3. 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 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 installed in any of the NSFs (e.g NSF B) and stop the process. Note that the I2NSF Controller may retry several times before giving up. 5. Otherwise, if the steps 1 to 3 are successful, the flow between NSF A and NSF B is protected by means of the IPsec SAs established by the I2NSF Controller. It is worth mentioning that the I2NSF Controller associates a lifetime to the new IPsec SAs. When this lifetime expires, the NSF will send a sadb-expire @@ -4238,27 +4248,27 @@ the outbound IPsec SA to B with SPIa2. At this point the new IPsec SAs are ready. 3. Once the I2NSF Controller receives confirmation from A and B that the outbound IPsec SAs have been installed, the I2NSF Controller, in parallel, deletes the old IPsec SAs from A (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and inbound SPIb1). 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 - 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 during step 1. 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 - 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 been successfully installed during step 2 and by deleting the inbound SAs created in step 1. 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 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 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