--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-00.txt 2018-03-05 15:14:35.747936094 -0800 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-01.txt 2018-03-05 15:14:35.839938298 -0800 @@ -1,18 +1,18 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: May 1, 2018 October 28, 2017 +Expires: September 6, 2018 March 5, 2018 Software-Defined Networking (SDN)-based IPsec Flow Protection - draft-ietf-i2nsf-sdn-ipsec-flow-protection-00 + draft-ietf-i2nsf-sdn-ipsec-flow-protection-01 Abstract This document describes the use case of 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. This document describes a mechanism based on the SDN paradigm to support the distribution and monitoring of IPsec information from a Security @@ -35,25 +35,25 @@ 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 May 1, 2018. + This Internet-Draft will expire on September 6, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -64,40 +64,40 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6 5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 5.2. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . 7 5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 5.3. Case 1 vs Case 2 . . . . . . . . . . . . . . . . . . . . 8 - 6. YANG configuration data models . . . . . . . . . . . . . . . 9 + 6. YANG configuration data models . . . . . . . . . . . . . . . 10 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 10 - 6.2. Security Association Database (SAD) Model . . . . . . . . 11 - 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 13 - 6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 14 - 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 16 + 6.2. Security Association Database (SAD) Model . . . . . . . . 12 + 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 14 + 6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 15 + 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 17 7.1. Host-to-Host or Gateway-to-gateway under the same - controller . . . . . . . . . . . . . . . . . . . . . . . 16 + controller . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Host-to-Host or Gateway-to-gateway under different - Security controllers . . . . . . . . . . . . . . . . . . 18 - 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 20 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 9.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 11.2. Informative References . . . . . . . . . . . . . . . . . 23 - Appendix A. Appendix A: YANG model IPsec Configuration data . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 + Security controllers . . . . . . . . . . . . . . . . . . 19 + 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 21 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 11.2. Informative References . . . . . . . . . . . . . . . . . 24 + Appendix A. Appendix A: YANG model IPsec Configuration data . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction Software-Defined Networking (SDN) is an architecture that enables users to directly program, orchestrate, control and manage network resources through software. SDN paradigm relocates the control of network resources to a dedicated network element, namely SDN controller. The SDN controller manages and configures the distributed network resources and provides an abstracted view of the network resources to the SDN applications. The SDN application can @@ -388,26 +388,49 @@ guess if there is a NAT configured between two hosts, apply the required policies to both NSFs besides activating the usage of UDP or TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). In those scenarios, the 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.sivakumar-yang-nat] a data model for NAT management. - Finally, if one of the NSF restarts it may lose part or all the IPsec - state. By default, the Security Controller can assume that all the - state has been lost and therefore it will have to send IKEv2, SPD and - PAD information to the NSF in case 1 and SPD and SAD information in - case 2. Nevertheless other more optimized options can be considered - (e.g. making iKEv2 configuration permanent between reboots). + Finally, if one of the NSF restarts, it may lose part or all the + IPsec state (affected NSF). By default, the Security Controller can + assume that all the state has been lost and therefore it will have to + send IKEv2, SPD and PAD information to the NSF in case 1 and SPD and + SAD information in case 2. + + In both cases, the Security Controller MUST be aware of the affected + NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, + it is receiving bad_spi notification from a particular NSF, etc...). + Moreover, the SDN controller MUST have a register about all the NSFs + that have IPsec SAS with the affected NSF. Therefore, it can know + the affected IPsec SAs. + + In Case 1, the SDN controller will configure the affected NSF with + the new IKEv2, SPD and PAD information. It has also to send new + parameters (e.g. a new fresh PSK) to the NSFs which have IKEv2 SAs + and IPsec SAs with the affected NSF. It can also instruct the + affected NSF to send INITIAL_CONTACT notification (It is TBD in the + model). Finally, the SDN controller will instruct the affected NSF + to start the IKEv2 negotiation with the new configuration. + + In Case 2, the SDN controller will have to: 1) install new SAD + entries and remove old SAD entries (and SPD entries if it is needed) + in the NSFs that had IPsec SAs with the affected NSF; and 2) install + new SPD entries and new SAD entries in the affected NSF to match with + the rest of the peers. + + Nevertheless other more optimized options can be considered (e.g. + making iKEv2 configuration permanent between reboots). 6. YANG configuration data models In order to support case 1 and case 2 we have modelled the different parameters and values that must be configured to manage IPsec SAs. Specifically, case 1 requires modelling IKEv2, SPD and PAD while case 2 requires models for the SPD and SAD. A single YANG file represents both cases though some part of the models are selectively activated depending a feature defined in the YANG file. For example, the IKE configuration is not enabled in case 2. @@ -927,21 +950,21 @@ Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular, according to this document, the Security Controller will handle cryptographic material so that the attacker may try to access this information. Although, we can assume this attack will not likely to happen due to the assumed security measurements to protect the Security Controller, some analysis of the impact deserves some analysis in the hypothetical the attack occurs. The impact is different depending on the case 1 or case 2. -9.1. Case 1: +9.1. Case 1 In this case 1, the controller sends IKE credentials (PSK, public/ private keys, certificates, etc...) to the NSFs. The general recommendation is that the Security Controller NEVER stores the IKE credentials after distributing them. Moreover the NSFs MUST NOT allow the reading of these values once they have been applied by the Security Controller (i.e. write only operations). If the attacker has access to the Security Controller during the period of time that key material is generated, it may access to these values. Since these values are used during NSF authentication in IKEv2, it may @@ -996,34 +1019,34 @@ [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, . 11.2. Informative References [I-D.ietf-i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security - Functions", draft-ietf-i2nsf-framework-08 (work in - progress), October 2017. + Functions", draft-ietf-i2nsf-framework-10 (work in + progress), November 2017. [I-D.ietf-i2nsf-problem-and-use-cases] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., and J. Jeong, "I2NSF Problem Statement and Use cases", draft-ietf-i2nsf-problem-and-use-cases-16 (work in progress), May 2017. [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-04 (work in - progress), July 2017. + Terminology", draft-ietf-i2nsf-terminology-05 (work in + progress), January 2018. [I-D.jeong-i2nsf-sdn-security-services-05] Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, "Software-Defined Networking Based Security Services using Interface to Network Security Functions", draft-jeong- i2nsf-sdn-security-services-05 (work in progress), July 2016. [I-D.pfkey-spd] Sakane, S., "PF_KEY Extensions for IPsec Policy Management @@ -1102,21 +1125,21 @@ [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, . [strongswan] CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based VPN Solution", April 2017. Appendix A. Appendix A: YANG model IPsec Configuration data - file "ietf-ipsec.yang" + file "ietf-ipsec@2018-01-08.yang" module ietf-ipsec { namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; prefix "eipsec"; import ietf-inet-types { prefix inet; } import ietf-yang-types { prefix yang; } organization "University of Murcia"; @@ -1132,21 +1155,21 @@ Gabriel Lopez Millan Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Tel: +34 868888504 email: gabilm@um.es "; description "Data model for IPSec"; - revision "2017-05-02" { + revision "2018-01-08" { description "Initial revision."; reference ""; } feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs typedef encryption-algorithm-t { type enumeration {