--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt 2019-08-05 04:13:52.058146627 -0700 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt 2019-08-05 04:13:52.270152017 -0700 @@ -1,20 +1,20 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: January 29, 2020 F. Pereniguez-Garcia +Expires: February 6, 2020 F. Pereniguez-Garcia University Defense Center - July 28, 2019 + August 5, 2019 Software-Defined Networking (SDN)-based IPsec Flow Protection - draft-ietf-i2nsf-sdn-ipsec-flow-protection-06 + draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 Abstract This document describes how providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller (aka. Security Controller) and establishes the requirements to support this service. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The SDN-based service described in this document allows the distribution and monitoring of IPsec information from a Security Controller to one or several flow-based @@ -35,21 +35,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 January 29, 2020. + This Internet-Draft will expire on February 6, 2020. Copyright Notice Copyright (c) 2019 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 @@ -93,22 +93,22 @@ 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67 Appendix D. Example of IKE case, tunnel mode (gateway-to- gateway) with X.509 certificate authentication. . . 77 Appendix E. Example of IKE-less case, transport mode (host-to- - host). . . . . . . . . . . . . . . . . . . . . . . . 80 - Appendix F. Examples of notifications. . . . . . . . . . . . . . 84 + host). . . . . . . . . . . . . . . . . . . . . . . . 81 + Appendix F. Examples of notifications. . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 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 dedicated network element, namely SDN Controller. The SDN controller (or Security Controller in the context of this document) manages and configures the distributed @@ -180,25 +180,24 @@ Finally, this work pays attention to the challenge "Lack of Mechanism for Dynamic Key Distribution to NSFs" defined in [RFC8192] in the particular case of the establishment and management of IPsec SAs. In fact,this I-D could be considered as a proper use case for this particular challenge in [RFC8192]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD 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. + "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. 3. Terminology This document uses the terminology described in [RFC7149], [RFC4301], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow], [ITU-T.X.1252], [ITU-T.X.800] and [I-D.ietf-i2nsf-terminology]. In addition, the following terms are defined below: o Software-Defined Networking. A set of techniques enabling to directly program, orchestrate, control, and manage network @@ -485,21 +484,21 @@ Security Controller receives a sadb-expire notification or it decides so, based on lifetime state data obtained from the NSF. To explain the rekeying process between two IPsec NSFs A and B, let assume that SPIa1 identifies the inbound IPsec SA in A, and SPIb1 the inbound IPsec SA in B. The rekeying process will take the following steps: 1. The Security Controller chooses two random values as SPI for the new inbound IPsec SAs: for example, SPIa2 for A and SPIb2 for B. - These numbers MUST not be in conflict with any IPsec SA in A or + These numbers MUST NOT be in conflict with any IPsec SA in A or B. Then, the Security Controller creates an inbound IPsec SA with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It can send this information simultaneously to A and B. 2. Once the Security Controller receives confirmation from A and B, the controller knows that the inbound IPsec A are correctly installed. Then it proceeds to send in parallel to A and B, the outbound IPsec SAs: it sends the outbound IPsec SA to A with SPIb2 and the outbound IPsec SA to B with SPIa2. At this point the new IPsec SAs are ready. @@ -583,27 +582,26 @@ because these NSFs inform the Security Controller. Based on this information, the Security Controller can guess if there is a NAT configured between two hosts, and apply the required policies to both NSFs besides activating the usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). For example, the Security Controller could directly request the NSF for specific data such as networking configuration, NAT support, etc. Protocols such as NETCONF or SNMP can be used here. For example, RFC 7317 [RFC7317] provides a YANG data model for system management or - [I-D.ietf-opsawg-nat-yang] a data model for NAT management. The - Security Controller can use this NETCONF module with a NSF to collect - NAT information or even configure a NAT network. In any case, if - this NETCONF module is not available in the NSF and the Security - Controller does not have a mechanism to know whether a host is behind - a NAT or not, then the IKE case should be the right choice and not - the IKE-less case. + [RFC8512] a data model for NAT management. The Security Controller + can use this NETCONF module with a NSF to collect NAT information or + even configure a NAT network. In any case, if this NETCONF module is + not available in the NSF and the Security Controller does not have a + mechanism to know whether a host is behind a NAT or not, then the IKE + case should be the right choice and not the IKE-less case. 5.3.4. NSF Discovery The assumption in this document is that, for both cases, before a NSF can operate in this system, it MUST be registered in the Security Controller. In this way, when the NSF comes to live and establishes a connection to the Security Controller, it knows that the NSF is valid for joining the system. Either during this registration process or when the NSF connects with @@ -1029,21 +1028,21 @@ 2. The Security Controller translates the flow-based security policies into IPsec SPD and SAD entries. 3. The Security Controller inserts these entries in both NSF A and NSF B IPsec databases (SPD and SAD). The following text describes how this happens between two NSFs A and B: * The Security Controller chooses two random values as SPIs: for example, SPIa1 for NSF A and SPIb1 for NSF B. These numbers - MUST not be in conflict with any IPsec SA in NSF A or NSF B. + MUST NOT be in conflict with any IPsec SA in NSF A or NSF B. It also generates fresh cryptographic material for the new inbound/outbound IPsec SAs and their parameters and send simultaneously the new inbound IPsec SA with SPIa1 and new outbound IPsec SAs with SPIb1 to NSF A; and the new inbound IPsec SA with SPIb1 and new outbound IPsec SAs with SPIa1 to B, together with the corresponding IPsec policies. * Once the Security Controller receives confirmation from NSF A and NSF B, the controller knows that the IPsec SAs are correctly installed and ready. @@ -1330,21 +1329,21 @@ 9.3. YANG modules The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. - The Network Configuration Access Control Model (NACM) [RFC8446] + The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes @@ -1438,26 +1437,20 @@ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . - [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., - and J. Jeong, "Interface to Network Security Functions - (I2NSF): Problem Statement and Use Cases", RFC 8192, - DOI 10.17487/RFC8192, July 2017, - . - [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 11.2. Informative References @@ -1466,45 +1459,38 @@ Carrel, D. and B. Weiss, "IPsec Key Exchange using a Controller", draft-carrel-ipsecme-controller-ike-01 (work in progress), March 2019. [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-08 (work in progress), July 2019. - [I-D.ietf-opsawg-nat-yang] - Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, - S., and Q. Wu, "A YANG Module for Network Address - Translation (NAT) and Network Prefix Translation (NPT)", - draft-ietf-opsawg-nat-yang-17 (work in progress), - September 2018. - [I-D.tran-ipsecme-yang] Tran, K., Wang, H., Nagaraj, V., and X. Chen, "Yang Data Model for Internet Protocol Security (IPsec)", draft-tran- ipsecme-yang-01 (work in progress), June 2015. [ITU-T.X.1252] "Baseline Identity Management Terms and Definitions", April 2010. [ITU-T.X.800] "Security Architecture for Open Systems Interconnection for CCITT Applications", March 1991. [ITU-T.Y.3300] "Recommendation ITU-T Y.3300", June 2014. [libreswan] - The Libreswan Project, "Libreswan VPN software", July + The Libreswan Project, "Libreswan VPN software", August 2019. [netconf-vpn] Stefan Wallin, "Tutorial: NETCONF and YANG", January 2014. [ONF-OpenFlow] ONF, "OpenFlow Switch Specification (Version 1.4.0)", October 2013. [ONF-SDN-Architecture] @@ -1537,31 +1523,43 @@ [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, . + [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., + and J. Jeong, "Interface to Network Security Functions + (I2NSF): Problem Statement and Use Cases", RFC 8192, + DOI 10.17487/RFC8192, July 2017, + . + [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . + [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., + Vinapamula, S., and Q. Wu, "A YANG Module for Network + Address Translation (NAT) and Network Prefix Translation + (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, + . + [strongswan] CESNET, "StrongSwan: the OpenSource IPsec-based VPN - Solution", July 2019. + Solution", August 2019. Appendix A. Appendix A: Common YANG model for IKE and IKE-less cases - file "ietf-ipsec-common@2019-07-07.yang" + file "ietf-ipsec-common@2019-08-05.yang" module ietf-ipsec-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-common"; prefix "ipsec-common"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } organization "IETF I2NSF Working Group"; @@ -1596,22 +1594,22 @@ 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 "2019-07-07" { - description "Revision 05"; + revision "2019-08-05" { + description "Revision 06"; reference "RFC XXXX: YANG Groupings and typedef for IKE and IKE-less case"; } 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 @@ -2103,21 +2101,21 @@ 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 + (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."; } @@ -2214,41 +2212,41 @@ states."; } } } } Appendix B. Appendix B: YANG model for IKE case - file "ietf-ipsec-ike@2019-07-07.yang" + file "ietf-ipsec-ike@2019-08-05.yang" module ietf-ipsec-ike { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ike"; prefix "ike"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } import ietf-crypto-types { prefix ct; reference - "draft-ietf-netconf-crypto-types-09: + "draft-ietf-netconf-crypto-types-10: Common YANG Data Types for Cryptography."; } import ietf-ipsec-common { prefix ic; reference "RFC XXXX: module ietf-ipsec-common, revision - 2019-07-07."; + 2019-08-05."; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model."; } organization "IETF I2NSF Working Group"; @@ -2286,22 +2284,22 @@ 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 "2019-07-07" { - description "Revision 5"; + revision "2019-08-05" { + description "Revision 6"; reference "RFC XXXX: YANG model for IKE case."; } typedef ike-spi { type uint64 { range "0..max"; } description "Security Parameter Index (SPI)'s IKE SA."; reference "Section 2.6 in RFC 7296."; @@ -2442,55 +2440,54 @@ 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 IPv4 - addressExample: 10.10.10.10."; + 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."; } } 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 + 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 address string. An example is, jsmith@example.com. The string - MUST not contain any + MUST NOT contain any terminators e.g., NULL, CR, etc.)."; reference "RFC 822."; } } case dnx509 { leaf dnx509 { type string; description @@ -3093,21 +3091,21 @@ particular, it provides the current number of IKE SAs."; } } /* container ipsec-ike */ } Appendix C. Appendix C: YANG model for IKE-less case - file "ietf-ipsec-ikeless@2019-07-07.yang" + file "ietf-ipsec-ikeless@2019-08-05.yang" module ietf-ipsec-ikeless { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless"; prefix "ikeless"; import ietf-yang-types { prefix yang; } @@ -3156,22 +3154,22 @@ 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 "2019-07-07" { - description "Revision 05"; + revision "2019-08-05" { + description "Revision 06"; reference "RFC XXXX: YANG model for IKE case."; } container ipsec-ikeless { description "Container for configuration of the IKE-less case. The container contains two additional containers: 'spd' and 'sad'. The first allows the Security Controller to configure IPsec policies in the Security Policy Database SPD, and the second @@ -3652,21 +3650,23 @@ 3600 7 3 18 30 - 15 + + 15 + nsf_h1_pad nsf_h2_pad nsf_h1-nsf_h2 @@ -3924,53 +3925,57 @@ Appendix F. Examples of notifications. Below we show several XML files that represent different types of notifications defined in the IKE-less YANG model, which are sent by the NSF to the Security Controller. The notifications happen in the IKE-less case. -in/trans/2001:DB8:123::200/2001:DB8:123::100 + in/trans/2001:DB8:123::200/2001:DB8:123::100 + true 1000000 1000 60 Figure 9: Example of sadb-expire notification. - in/trans/2001:DB8:123::200/2001:DB8:123::100 + in/trans/2001:DB8:123::200/2001:DB8:123::100 + 2001:DB8:123::200/128 2001:DB8:123::100/128 any 0 0 0 0 Figure 10: Example of sadb-acquire notification. - - in/trans/2001:DB8:123::200/2001:DB8:123::100 + + in/trans/2001:DB8:123::200/2001:DB8:123::100 + Figure 11: Example of sadb-seq-overflow notification. 666 Figure 12: Example of sadb-bad-spi notification.