draft-ietf-i2nsf-sdn-ipsec-flow-protection-00.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-01.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: May 1, 2018 October 28, 2017 Expires: September 6, 2018 March 5, 2018
Software-Defined Networking (SDN)-based IPsec Flow Protection 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 Abstract
This document describes the use case of providing IPsec-based flow This document describes the use case of providing IPsec-based flow
protection by means of a Software-Defined Network (SDN) controller protection by means of a Software-Defined Network (SDN) controller
(aka. Security Controller) and establishes the requirements to (aka. Security Controller) and establishes the requirements to
support this service. It considers two main well-known scenarios in support this service. It considers two main well-known scenarios in
IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document IPsec: (i) gateway-to-gateway and (ii) host-to-host. This document
describes a mechanism based on the SDN paradigm to support the describes a mechanism based on the SDN paradigm to support the
distribution and monitoring of IPsec information from a Security distribution and monitoring of IPsec information from a Security
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 1, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6
5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6 5.1. Case 1: IKE/IPsec in the NSF . . . . . . . . . . . . . . 6
5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7 5.1.1. Interface Requirements for Case 1 . . . . . . . . . . 7
5.2. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . 7 5.2. Case 2: IPsec (no IKE) in the NSF . . . . . . . . . . . . 7
5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8 5.2.1. Interface Requirements for Case 2 . . . . . . . . . . 8
5.3. Case 1 vs 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.1. Security Policy Database (SPD) Model . . . . . . . . . . 10
6.2. Security Association Database (SAD) Model . . . . . . . . 11 6.2. Security Association Database (SAD) Model . . . . . . . . 12
6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 13 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 14
6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 14 6.4. Internet Key Exchange (IKE) Model . . . . . . . . . . . . 15
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 16 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 17
7.1. Host-to-Host or Gateway-to-gateway under the same 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 7.2. Host-to-Host or Gateway-to-gateway under different
Security controllers . . . . . . . . . . . . . . . . . . 18 Security controllers . . . . . . . . . . . . . . . . . . 19
8. Implementation notes . . . . . . . . . . . . . . . . . . . . 20 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Case 1: . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Appendix A: YANG model IPsec Configuration data . . 26 Appendix A. Appendix A: YANG model IPsec Configuration data . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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. SDN paradigm relocates the control of resources through software. SDN paradigm relocates the control of
network resources to a dedicated network element, namely SDN network resources to a dedicated network element, namely SDN
controller. The SDN controller manages and configures the controller. The SDN controller manages and configures the
distributed network resources and provides an abstracted view of the distributed network resources and provides an abstracted view of the
network resources to the SDN applications. The SDN application can network resources to the SDN applications. The SDN application can
skipping to change at page 9, line 38 skipping to change at page 9, line 38
guess if there is a NAT configured between two hosts, apply the guess if there is a NAT configured between two hosts, apply the
required policies to both NSFs besides activating the usage of UDP or required policies to both NSFs besides activating the usage of UDP or
TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]). TCP/TLS encapsulation of ESP packets ([RFC3948], [RFC8229]).
In those scenarios, the Controller could directly request the NSF for In those scenarios, the Controller could directly request the NSF for
specific data such as networking configuration, NAT support, etc. specific data such as networking configuration, NAT support, etc.
Protocols such as NETCONF or SNMP can be used here. For example, RFC Protocols such as NETCONF or SNMP can be used here. For example, RFC
7317 [RFC7317] provides a YANG data model for system management or 7317 [RFC7317] provides a YANG data model for system management or
[I-D.sivakumar-yang-nat] a data model for NAT management. [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 Finally, if one of the NSF restarts, it may lose part or all the
state. By default, the Security Controller can assume that all the IPsec state (affected NSF). By default, the Security Controller can
state has been lost and therefore it will have to send IKEv2, SPD and assume that all the state has been lost and therefore it will have to
PAD information to the NSF in case 1 and SPD and SAD information in send IKEv2, SPD and PAD information to the NSF in case 1 and SPD and
case 2. Nevertheless other more optimized options can be considered SAD information in case 2.
(e.g. making iKEv2 configuration permanent between reboots).
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 6. YANG configuration data models
In order to support case 1 and case 2 we have modelled the different 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. parameters and values that must be configured to manage IPsec SAs.
Specifically, case 1 requires modelling IKEv2, SPD and PAD while case Specifically, case 1 requires modelling IKEv2, SPD and PAD while case
2 requires models for the SPD and SAD. A single YANG file represents 2 requires models for the SPD and SAD. A single YANG file represents
both cases though some part of the models are selectively activated both cases though some part of the models are selectively activated
depending a feature defined in the YANG file. For example, the IKE depending a feature defined in the YANG file. For example, the IKE
configuration is not enabled in case 2. configuration is not enabled in case 2.
skipping to change at page 22, line 5 skipping to change at page 23, line 5
Controller is a key entity in the infrastructure and MUST be Controller is a key entity in the infrastructure and MUST be
protected accordingly. In particular, according to this document, protected accordingly. In particular, according to this document,
the Security Controller will handle cryptographic material so that the Security Controller will handle cryptographic material so that
the attacker may try to access this information. Although, we can the attacker may try to access this information. Although, we can
assume this attack will not likely to happen due to the assumed assume this attack will not likely to happen due to the assumed
security measurements to protect the Security Controller, some security measurements to protect the Security Controller, some
analysis of the impact deserves some analysis in the hypothetical the analysis of the impact deserves some analysis in the hypothetical the
attack occurs. The impact is different depending on the case 1 or attack occurs. The impact is different depending on the case 1 or
case 2. case 2.
9.1. Case 1: 9.1. Case 1
In this case 1, the controller sends IKE credentials (PSK, public/ In this case 1, the controller sends IKE credentials (PSK, public/
private keys, certificates, etc...) to the NSFs. The general private keys, certificates, etc...) to the NSFs. The general
recommendation is that the Security Controller NEVER stores the IKE recommendation is that the Security Controller NEVER stores the IKE
credentials after distributing them. Moreover the NSFs MUST NOT credentials after distributing them. Moreover the NSFs MUST NOT
allow the reading of these values once they have been applied by the allow the reading of these values once they have been applied by the
Security Controller (i.e. write only operations). If the attacker Security Controller (i.e. write only operations). If the attacker
has access to the Security Controller during the period of time that has access to the Security Controller during the period of time that
key material is generated, it may access to these values. Since key material is generated, it may access to these values. Since
these values are used during NSF authentication in IKEv2, it may these values are used during NSF authentication in IKEv2, it may
skipping to change at page 23, line 30 skipping to change at page 24, line 30
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-i2nsf-framework] [I-D.ietf-i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-08 (work in Functions", draft-ietf-i2nsf-framework-10 (work in
progress), October 2017. progress), November 2017.
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "I2NSF Problem Statement and Use cases", and J. Jeong, "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-16 (work in draft-ietf-i2nsf-problem-and-use-cases-16 (work in
progress), May 2017. progress), May 2017.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-04 (work in Terminology", draft-ietf-i2nsf-terminology-05 (work in
progress), July 2017. progress), January 2018.
[I-D.jeong-i2nsf-sdn-security-services-05] [I-D.jeong-i2nsf-sdn-security-services-05]
Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
"Software-Defined Networking Based Security Services using "Software-Defined Networking Based Security Services using
Interface to Network Security Functions", draft-jeong- Interface to Network Security Functions", draft-jeong-
i2nsf-sdn-security-services-05 (work in progress), July i2nsf-sdn-security-services-05 (work in progress), July
2016. 2016.
[I-D.pfkey-spd] [I-D.pfkey-spd]
Sakane, S., "PF_KEY Extensions for IPsec Policy Management Sakane, S., "PF_KEY Extensions for IPsec Policy Management
skipping to change at page 26, line 7 skipping to change at page 27, line 7
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[strongswan] [strongswan]
CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based
VPN Solution", April 2017. VPN Solution", April 2017.
Appendix A. Appendix A: YANG model IPsec Configuration data Appendix A. Appendix A: YANG model IPsec Configuration data
<CODE BEGINS> file "ietf-ipsec.yang" <CODE BEGINS> file "ietf-ipsec@2018-01-08.yang"
module ietf-ipsec { module ietf-ipsec {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec";
prefix "eipsec"; prefix "eipsec";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
organization "University of Murcia"; organization "University of Murcia";
skipping to change at page 26, line 37 skipping to change at page 27, line 37
Gabriel Lopez Millan Gabriel Lopez Millan
Dept. Information and Communications Engineering (DIIC) Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia Faculty of Computer Science-University of Murcia
30100 Murcia - Spain 30100 Murcia - Spain
Tel: +34 868888504 Tel: +34 868888504
email: gabilm@um.es email: gabilm@um.es
"; ";
description "Data model for IPSec"; description "Data model for IPSec";
revision "2017-05-02" { revision "2018-01-08" {
description description
"Initial revision."; "Initial revision.";
reference ""; reference "";
} }
feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs 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 feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs
typedef encryption-algorithm-t { typedef encryption-algorithm-t {
type enumeration { type enumeration {
 End of changes. 14 change blocks. 
34 lines changed or deleted 57 lines changed or added

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