--- 1/draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt 2019-07-29 11:13:13.447591000 -0700 +++ 2/draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.txt 2019-07-29 11:13:13.643595946 -0700 @@ -1,20 +1,20 @@ I2NSF R. Marin-Lopez Internet-Draft G. Lopez-Millan Intended status: Standards Track University of Murcia -Expires: January 8, 2020 F. Pereniguez-Garcia +Expires: January 29, 2020 F. Pereniguez-Garcia University Defense Center - July 7, 2019 + July 28, 2019 Software-Defined Networking (SDN)-based IPsec Flow Protection - draft-ietf-i2nsf-sdn-ipsec-flow-protection-05 + draft-ietf-i2nsf-sdn-ipsec-flow-protection-06 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 8, 2020. + This Internet-Draft will expire on January 29, 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 @@ -65,49 +65,51 @@ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 5.2.1. Interface Requirements for IKE-less case . . . . . . 8 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10 - 5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 11 + 5.3.2. NSF state loss. . . . . . . . . . . . . . . . . . . . 12 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12 - 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 12 + 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 13 6. YANG configuration data models . . . . . . . . . . . . . . . 13 - 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 - 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 + 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 14 + 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20 7.1. Host-to-host or gateway-to-gateway under the same Security Controller . . . . . . . . . . . . . . . . . . . 20 7.2. Host-to-host or gateway-to-gateway under different - Security Controllers . . . . . . . . . . . . . . . . . . 22 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 25 - 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 11.2. Informative References . . . . . . . . . . . . . . . . . 27 + Security Controllers . . . . . . . . . . . . . . . . . . 24 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 29 + 9.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 29 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 11.2. Informative References . . . . . . . . . . . . . . . . . 32 + Appendix A. Appendix A: Common YANG model for IKE and IKE-less - cases . . . . . . . . . . . . . . . . . . . . . . . 30 - Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 43 - Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 62 + 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. . . 72 + gateway) with X.509 certificate authentication. . . 77 Appendix E. Example of IKE-less case, transport mode (host-to- - host). . . . . . . . . . . . . . . . . . . . . . . . 75 - Appendix F. Examples of notifications. . . . . . . . . . . . . . 79 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 + host). . . . . . . . . . . . . . . . . . . . . . . . 80 + Appendix F. Examples of notifications. . . . . . . . . . . . . . 84 + 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 network resources and provides an abstracted view of the network @@ -412,37 +414,49 @@ Moreover hosts can install easily an IKE implementation. As downside, the NSF needs more resources to hold IKEv2. Moreover, the IKEv2 implementation needs to implement an internal interface so that the IKE configuration sent by the Security Controller can be enforced in runtime. Alternatively, IKE-less case allows lighter NSFs (no IKEv2 implementation), which benefits the deployment in constrained NSFs. Moreover, IKEv2 does not need to be performed in gateway-to-gateway and host-to-host scenarios under the same Security Controller (see - Section 7.1). On the contrary, the overload of creating fresh IPsec - SAs is shifted to the Security Controller since IKEv2 is not in the - NSF. As a consequence, this may result in a more complex - implementation in the controller side. This overload may create some - scalability issues when the number of NSFs is high. + Section 7.1). On the contrary, the overload of creating and managing + IPsec SAs is shifted to the Security Controller since IKEv2 is not in + the NSF. As a consequence, this may result in a more complex + implementation in the controller side in comparison with IKE case. + For example, the Security Controller have to deal with the latency + existing in the path between the Security Controller and the NSF in + order to solve tasks such as, rekey or creation and installation of + new IPsec SAs. However, this is not specific to our contribution but + a general aspect in any SDN-based network. In summary, this overload + may create some scalability and performance issues when the number of + NSFs is high. - In general, literature around SDN-based network management using a - centralized Security Controller is aware about scalability issues and - solutions have been already provided (e.g. hierarchical Security - Controllers; having multiple replicated Security Controllers, etc). - In the context of SDN-based IPsec management, one straight way to - reduce the overhead and the potential scalability issue in the - Security Controller is to apply the IKE case described in this - document, since the IPsec SAs are managed between NSFs without the - involvement of the Security Controller at all, except by the initial - IKE configuration provided by the Security Controller. Other - solutions, such as Controller-IKE + Nevertheless, literature around SDN-based network management using a + centralized Security Controller is aware about scalability and + performance issues and solutions have been already provided and + discussed (e.g. hierarchical Security Controllers; having multiple + replicated Security Controllers, dedicated high-speed management + networks, etc). In the context of SDN-based IPsec management, one + way to reduce the latency and alleviate some performance issues can + be the installation of the IPsec policies and IPsec SAs at the same + time (proactive mode, as described in Section 7.1) instead of waiting + for notifications (e.g. a notification sadb-acquire when a new IPsec + SA is required) to proceed with the IPsec SA installations (reactive + mode). Another way to reduce the overhead and the potential + scalability and performance issues in the Security Controller is to + apply the IKE case described in this document, since the IPsec SAs + are managed between NSFs without the involvement of the Security + Controller at all, except by the initial IKE configuration provided + by the Security Controller. Other solutions, such as Controller-IKE [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide their DH public keys to the Security Controller, so that the Security Controller distributes all public keys to all peers. All peers can calculate a unique pairwise secret for each other peer and there is no inter-NSF messages. A rekey mechanism is further described in [I-D.carrel-ipsecme-controller-ike]. In terms of security, IKE case provides better security properties than IKE-less case, as we discuss in section Section 9. The main reason is that the NSFs are generating the session keys and not the @@ -464,23 +478,24 @@ the Security Controller installs first the new inbound SAs in both NSFs and then, the outbound IPsec SAs. In other words, for the IKE-less case, the Security Controller needs to take care of the rekeying process. When the IPsec SA is going to expire (e.g. IPsec SA soft lifetime), it has to create a new IPsec SA and remove the old one. This rekeying process starts when the 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 peers A and B, let + 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. + 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 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 @@ -488,20 +503,41 @@ 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. 3. Once the Security Controller receives confirmation from A and B that the outbound IPsec SAs have been installed, the Security 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 Security Controller is trying to install a new inbound + IPsec SA) the Security 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 Security Controller is + trying to install the new outbound IPsec SA), the Security 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 an 2 are successful and the step 3 fails the Security + 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 Security 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 + SAs will be removed when the hard lifetime is reached. + 5.3.2. NSF state loss. If one of the NSF restarts, it will lose 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 the IKE case, and SPD and SAD information in IKE-less case. In both cases, the Security Controller is aware of the affected NSF (e.g. the NETCONF/TCP connection is broken with the affected NSF, the @@ -918,101 +953,145 @@ Security. Pol. | |IPsec Policies| | | | | +--------------+ +--------------+ | | | | | | | | | +--------------------------|-----|-------+ | | | (3) | |-------------------------+ +---| V V +----------------------+ +----------------------+ - | NSF1 |<=======>| NSF2 | + | NSF A |<=======>| NSF B | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | +----------------------+ (4) +----------------------+ Figure 3: Host-to-host / gateway-to-gateway single Security Controller for the IKE case. Figure 3 describes the IKE case: 1. The administrator defines general flow-based security policies. - The Security Controller looks for the NSFs involved (NSF1 and - NSF2). + The Security Controller looks for the NSFs involved (NSF A and + NSF B). 2. The Security Controller generates IKEv2 credentials for them and translates the policies into SPD and PAD entries. 3. The Security Controller inserts an IKEv2 configuration that - include the SPD and PAD entries in both NSF1 and NSF2. + includes the SPD and PAD entries in both NSF A and NSF B. If + some of operations with NSF A and NSF B fail the Security + Controller will stop the process and perform a rollback operation + by deleting any IKEv2, SPD and PAD configuration that had been + successfully installed in NSF A or B. - 4. The flow is protected by means of the IPsec SA established with - IKEv2. + 4. If the previous step is successful, the flow is protected by + means of the IPsec SA established with IKEv2. +----------------------------------------+ | (1) Security Controller | Flow-based | | Security -----------| | Policy | V | | +---------------+ (2)+-------------+ | | |Translate into |--->| South. Prot.| | | |IPsec policies | | | | | +---------------+ +-------------+ | | | | | | | | | +-------------------------| --- |--------+ | | | (3) | |----------------------+ +--| V V +------------------+ +------------------+ - | NSF1 |<=====>| NSF2 | + | NSF A |<=====>| NSF B | |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | +------------------+ +------------------+ Figure 4: Host-to-host / gateway-to-gateway single Security Controller for IKE-less case. In the IKE-less case, flow-based security policies defined by the administrator are translated into IPsec SPD entries and inserted into the corresponding NSFs. Besides, fresh SAD entries will be also generated by the Security Controller and enforced in the NSFs. In this case, the Security Controller does not run any IKEv2 implementation (neither the NSFs), and it provides the cryptographic material for the IPsec SAs. These keys will be also distributed securely through the southbound interface. Note that this is possible because both NSFs are managed by the same Security Controller. Figure 4 describes the IKE-less case, when a data packet needs to be - protected in the path between the NSF1 and NSF2: + protected in the path between the NSF A and NSF B: 1. The administrator establishes the flow-based security policies, and the Security Controller looks for the involved NSFs. 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 NSF1 and - NSF2 IPsec databases. It associates a lifetime to the IPsec SAs. - When this lifetime expires, the NSF will send a sadb-expire - notification to the Security Controller in order to start the - rekeying process. + 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. + 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. + + If some of the operations described above fails (e.g. the NSF A + reports an error when the Security Controller is trying to + install the SPD entry, the new inbound and outbound IPsec SAs) + the Security 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: the Security Controller may retry several + times before giving up). Other alternative to this operation is: + the Security Controller sends first the IPsec policies and new + inbound IPsec SAs to A and B and once it obtains a successful + confirmation of these operations from NSF A and NSF B, it + proceeds with installing to the new outbound IPsec SAs. However, + this may increase the latency to complete the process. As an + advantage, no traffic is sent over the network until the IPsec + SAs are completely operative. In any case other alternatives may + be possible. Finally, it is worth mentioning that the Security + Controller associates a lifetime to the new IPsec SAs. When this + lifetime expires, the NSF will send a sadb-expire notification to + the Security Controller in order to start the rekeying process. 4. The flow is protected with the IPsec SA established by the Security Controller. - It is also possible that the Security Controller only installs the - SPD entries in step 2. In such a case, when a data packet requires - to be protected with IPsec, the NSF that saw first the data packet - will send a sadb-acquire notification that informs the Security - Controller that SAD entries with the IPsec SAs required to process - the data packet needs to be installed in the NSFs. + Instead of installing IPsec policies in the SPD and IPsec SAs in the + SAD in step 3 (proactive mode), it is also possible that the Security + Controller only installs the SPD entries in step 3 (reactive mode). + In such a case, when a data packet requires to be protected with + IPsec, the NSF that saw first the data packet will send a sadb- + acquire notification that informs the Security Controller that needs + SAD entries with the IPsec SAs to process the data packet. In such + as reactive mode, since IPsec policies are already installed in the + SPD, the Security Controller installs first the new IPsec SAs in NSF + A and B with the operations described in step 3 but without sending + any IPsec policies. Again, if some of the operations installing the + new inbound/outbound IPsec SAs fail, the Security Controller stops + the process and performs a rollback operation by deleting any new + inbound/outbound SAs that had been successfully installed. Both NSFs could be two hosts that exchange traffic and require to establish an end-to-end security association to protect their communications (host-to-host) or two gateways (gateway-to-gateway), for example, within an enterprise that needs to protect the traffic between the networks of two branch offices. Applicability of these configurations appear in current and new networking scenarios. For example, SD-WAN technologies are providing dynamic and on-demand VPN connections between branch offices, or @@ -1031,110 +1110,144 @@ associations in a centralized point with an abstracted view of the network. 2. Any NSF deployed in the system does not need manual configuration, therefore allowing its deployment in an automated manner. 7.2. Host-to-host or gateway-to-gateway under different Security Controllers - It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the - control of two different Security Controllers. This may happen, for - example, when two organizations, namely Enterprise A and Enterprise - B, have their headquarters interconnected through a WAN connection - and they both have deployed a SDN-based architecture to provide - connectivity to all their clients. + It is also possible that two NSFs (i.e. NSF A and NSF B) are under + the control of two different Security Controllers. This may happen, + for example, when two organizations, namely Enterprise A and + Enterprise B, have their headquarters interconnected through a WAN + connection and they both have deployed a SDN-based architecture to + provide connectivity to all their clients. +-------------+ +-------------+ | | | | Flow-based| Security |<=========>| Security <--Flow-based Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. (1) | A | | B | (2) +-------------+ +-------------+ | | | (4) (4) | V V +--------------------+ +--------------------+ - | NSF1 |<========>| NSF2 | + | NSF A |<=======>| NSF B | |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| +--------------------+ (5) +--------------------+ Figure 5: Different Security Controllers in the IKE case. Figure 5 describes IKE case when two Security Controllers are involved in the process. 1. The A's administrator establishes general Flow-based Security Policies in Security Controller A. 2. The B's administrator establishes general Flow-based Security Policies in Security Controller B. 3. The Security Controller A realizes that protection is required - between the NSF1 and NSF2, but the NSF2 is under the control of - another Security Controller (Security Controller B), so it starts - negotiations with the other controller to agree on the IPsec SPD - policies and IKEv2 credentials for their respective NSFs. NOTE: - This may require extensions in the East/West interface. + between the NSF A and NSF B, but the NSF B is under the control + of another Security Controller (Security Controller B), so it + starts negotiations with the other controller to agree on the + IPsec SPD policies and IKEv2 credentials for their respective + NSFs. NOTE: This may require extensions in the East/West + interface. 4. Then, both Security Controllers enforce the IKEv2 credentials, related parameters and the SPD and PAD entries in their respective NSFs. 5. The flow is protected with the IPsec SAs established with IKEv2 between both NSFs. +--------------+ +--------------+ | | | | Flow-based. ---> | | <---Flow-based Prot. | Security |<===========>| Security |Sec. Pol.(1)| Controller | (3) | Controller |Pol. (2) | A | | B | +--------------+ +--------------+ | | | (4) (4) | V V +--------------+ (5) +--------------+ - | NSF1 |<==============>| NSF2 | + | NSF A |<==============>| NSF B | |IPsec(SPD/SAD)| |IPsec(SPD/SAD)| +--------------+ +--------------+ Figure 6: Different Security Controllers in the IKE-less case. Figure 6 describes IKE-less case when two Security Controllers are involved in the process. 1. The A's administrator establishes general Flow Protection Policies in Security Controller A. 2. The B's administrator establishes general Flow Protection Policies in Security Controller B. - 3. The Security Controller A realizes that the flow between NSF1 and - NSF2 MUST be protected. Nevertheless, it notices that NSF2 is - under the control of another Security Controller B, so it starts - negotiations with the other controller to agree on the IPsec SPD - and SAD entries that define the IPsec SAs. NOTE: It would worth - evaluating IKEv2 as the protocol for the East/West interface in - this case. + 3. The Security Controller A realizes that the flow between NSF B + and NSF B MUST be protected. Nevertheless, it notices that NSF B + is under the control of another Security Controller B, so it + starts negotiations with the other controller to agree on the + IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It + would worth evaluating IKEv2 as the protocol for the East/West + interface in this case. 4. Once the Security Controllers have agreed on the key material and the details of the IPsec SAs, they both enforce this information into their respective NSFs. 5. The flow is protected with the IPsec SAs established by both Security Controllers in their respective NSFs. 8. IANA Considerations - TBD + This document registers three URIs in the "ns" subregistry of the + IETF XML Registry [RFC3688]. Following the format in [RFC3688], the + following registrations are requested: + + URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-common + Registrant Contact: The I2NSF WG of the IETF. + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike + Registrant Contact: The I2NSF WG of the IETF. + XML: N/A, the requested URI is an XML namespace. + + URI: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless + Registrant Contact: The I2NSF WG of the IETF. + XML: N/A, the requested URI is an XML namespace. + + This document registers three YANG modules in the "YANG Module Names" + registry [RFC6020]. Following the format in [RFC6020], the following + registrations are requested: + + Name: ietf-ipsec-common + Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-common + Prefix: ic + Reference: RFC XXXX + + Name: ietf-ipsec-ike + Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ike + Prefix: ike + Reference: RFC XXXX + + Name: ietf-ipsec-ikeless + Namespace: urn:ietf:params:xml:ns:yang:ietf-ipsec-ikeless + Prefix: ikeless + Reference: RFC XXXX 9. Security Considerations First of all, this document shares all the security issues of SDN that are specified in the "Security Considerations" section of [ITU-T.Y.3300] and [RFC8192]. On the one hand, it is important to note that there MUST exit a security association between the Security Controller and the NSFs to protect of the critical information (cryptographic keys, @@ -1207,52 +1320,153 @@ that it MUST NOT store the keys after distributing them. Moreover, the NSFs receiving private key material MUST NOT allow the reading of these values by any other entity (including the Security Controller itself) once they have been applied (i.e. write only operations) into the NSFs. Nevertheless, if the attacker has access to the Security Controller during the period of time that key material is generated, it may obtain these values. In other words, the attacker might be able to observe the IPsec traffic and decrypt, or even modify and re- encrypt the traffic between peers. +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] + 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 + and their sensitivity/vulnerability: + + The YANG modules describe configuration data for the IKE case (ietf- + ipsec-ike) and IKE-less case (ietf-ipsec-ikeless). There is a common + module (ietf-ipsec-common) used in both cases. + + For the IKE case (ietf-ipsec-ike): + + /ipsec-ike: The entire container in this module is sensitive to + write operations. An attacker may add/modify the credentials + to be used for the authentication (e.g. to impersonate a NSF), + the trust root (e.g. changing the trusted CA certificates), + the cryptographic algorithms (allowing a downgrading attack), + the IPsec policies (e.g. by allowing leaking of data traffic by + changing to a allow policy), and in general changing the IKE SA + conditions and credentials between any NSF. + + For the IKE-less case (ietf-ipsec-ikeless): + + /ipsec-ikeless: The entire container in this module is + sensitive to write operations. An attacker may add/modify/ + delete any IPsec policies (e.g. by allowing leaking of data + traffic by changing to a allow policy) in the /ipsec-ikeless/ + spd container, and add/modify/delete any IPsec SAs between two + NSF by means of /ipsec-ikeless/sad container and, in general + changing any IPsec SAs and IPsec policies between any NSF. + + Some of the readable data nodes in this YANG module may be considered + sensitive or vulnerable in some network environments. It is thus + important to control read access (e.g., via get, get-config, or + notification) to these data nodes. These are the subtrees and data + nodes and their sensitivity/vulnerability: + + For the IKE case (ietf-ipsec-ike): + + /ipsec-ike/pad: This container includes sensitive information + to read operations. This information should never be returned + to a client. For example, cryptographic material configured in + the NSFs: peer-authentication/pre-shared/secret and peer- + authentication/digital-signature/private-key are already + protected by the NACM extension "default-deny-all" in this + document. + + For the IKE-less case (ietf-ipsec-ikeless): + + /ipsec-ikeless/sad/ipsec-sa-config/esp-sa: This container + includes symmetric keys for the IPsec SAs. For example, + encryption/key contains a ESP encryption key value and + encryption/iv contains a initialization vector value. + Similarly, integrity/key has ESP integrity key value. Those + values must not be read by anyone and are protected by the NACM + extension "default-deny-all" in this document. + 10. Acknowledgements - Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, - Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda - Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- - Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable - comments. + Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan, + David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham + Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos, + Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez + and Ruben Ricart for their valuable comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . + [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., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + . + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + . + [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 [I-D.carrel-ipsecme-controller-ike] 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) @@ -1294,20 +1508,24 @@ October 2013. [ONF-SDN-Architecture] "SDN Architecture", June 2014. [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, DOI 10.17487/RFC2367, July 1998, . + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, . [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, . @@ -1385,41 +1603,41 @@ (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision "2019-07-07" { description "Revision 05"; reference "RFC XXXX: YANG Groupings and typedef for IKE and IKE-less case"; } typedef encryption-algorithm-type { - type uint32; + type uint16; description - "The encryption algorithm is specified with a 32-bit + "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 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 { - type uint32; + type uint16; description - "The integrity algorithm is specified with a 32-bit + "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 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 @@ -1759,21 +1977,21 @@ 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.2.1 and Annex C in RFC 4301."; + "Section 5.1.2 and Annex 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."; @@ -2114,21 +2332,21 @@ 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 uint32; + 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."; } typedef auth-protocol-type { @@ -2718,21 +2936,21 @@ "This container carries the configuration of a IPsec policy."; uses ic:ipsec-policy-grouping; } description "List of entries which will constitute the representation of the SPD. Since we have IKE in this case, it is only required to send a IPsec policy from this NSF where 'local' is this NSF and - remote the other NSF. The IKE + '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 {