draft-ietf-i2nsf-sdn-ipsec-flow-protection-05.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-06.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: January 8, 2020 F. Pereniguez-Garcia Expires: January 29, 2020 F. Pereniguez-Garcia
University Defense Center University Defense Center
July 7, 2019 July 28, 2019
Software-Defined Networking (SDN)-based IPsec Flow Protection 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 Abstract
This document describes how providing IPsec-based flow protection by This document describes how providing IPsec-based flow protection by
means of a Software-Defined Network (SDN) controller (aka. Security means of a Software-Defined Network (SDN) controller (aka. Security
Controller) and establishes the requirements to support this service. Controller) and establishes the requirements to support this service.
It considers two main well-known scenarios in IPsec: (i) gateway-to- It considers two main well-known scenarios in IPsec: (i) gateway-to-
gateway and (ii) host-to-host. The SDN-based service described in gateway and (ii) host-to-host. The SDN-based service described in
this document allows the distribution and monitoring of IPsec this document allows the distribution and monitoring of IPsec
information from a Security Controller to one or several flow-based information from a Security Controller to one or several flow-based
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 January 8, 2020. This Internet-Draft will expire on January 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SDN-based IPsec management description . . . . . . . . . . . 6 5. SDN-based IPsec management description . . . . . . . . . . . 6
5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6 5.1. IKE case: IKE/IPsec in the NSF . . . . . . . . . . . . . 6
5.1.1. Interface Requirements for IKE case . . . . . . . . . 7 5.1.1. Interface Requirements for IKE case . . . . . . . . . 7
5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7 5.2. IKE-less case: IPsec (no IKEv2) in the NSF. . . . . . . . 7
5.2.1. Interface Requirements for IKE-less case . . . . . . 8 5.2.1. Interface Requirements for IKE-less case . . . . . . 8
5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9 5.3. IKE case vs IKE-less case . . . . . . . . . . . . . . . . 9
5.3.1. Rekeying process. . . . . . . . . . . . . . . . . . . 10 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.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 12
5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 12 5.3.4. NSF Discovery . . . . . . . . . . . . . . . . . . . . 13
6. YANG configuration data models . . . . . . . . . . . . . . . 13 6. YANG configuration data models . . . . . . . . . . . . . . . 13
6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 13 6.1. IKE case model . . . . . . . . . . . . . . . . . . . . . 14
6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 16 6.2. IKE-less case model . . . . . . . . . . . . . . . . . . . 17
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 20
7.1. Host-to-host or gateway-to-gateway under the same 7.1. Host-to-host or gateway-to-gateway under the same
Security Controller . . . . . . . . . . . . . . . . . . . 20 Security Controller . . . . . . . . . . . . . . . . . . . 20
7.2. Host-to-host or gateway-to-gateway under different 7.2. Host-to-host or gateway-to-gateway under different
Security Controllers . . . . . . . . . . . . . . . . . . 22 Security Controllers . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. IKE case . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 26 9.2. IKE-less case . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9.3. YANG modules . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Appendix A: Common YANG model for IKE and IKE-less Appendix A. Appendix A: Common YANG model for IKE and IKE-less
cases . . . . . . . . . . . . . . . . . . . . . . . 30 cases . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 43 Appendix B. Appendix B: YANG model for IKE case . . . . . . . . 48
Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 62 Appendix C. Appendix C: YANG model for IKE-less case . . . . . . 67
Appendix D. Example of IKE case, tunnel mode (gateway-to- 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- Appendix E. Example of IKE-less case, transport mode (host-to-
host). . . . . . . . . . . . . . . . . . . . . . . . 75 host). . . . . . . . . . . . . . . . . . . . . . . . 80
Appendix F. Examples of notifications. . . . . . . . . . . . . . 79 Appendix F. Examples of notifications. . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
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. The SDN paradigm relocates the control resources through software. The SDN paradigm relocates the control
of network resources to a dedicated network element, namely SDN of network resources to a dedicated network element, namely SDN
Controller. The SDN controller (or Security Controller in the Controller. The SDN controller (or Security Controller in the
context of this document) manages and configures the distributed context of this document) manages and configures the distributed
network resources and provides an abstracted view of the network network resources and provides an abstracted view of the network
skipping to change at page 9, line 48 skipping to change at page 9, line 48
Moreover hosts can install easily an IKE implementation. As Moreover hosts can install easily an IKE implementation. As
downside, the NSF needs more resources to hold IKEv2. Moreover, the downside, the NSF needs more resources to hold IKEv2. Moreover, the
IKEv2 implementation needs to implement an internal interface so that IKEv2 implementation needs to implement an internal interface so that
the IKE configuration sent by the Security Controller can be enforced the IKE configuration sent by the Security Controller can be enforced
in runtime. in runtime.
Alternatively, IKE-less case allows lighter NSFs (no IKEv2 Alternatively, IKE-less case allows lighter NSFs (no IKEv2
implementation), which benefits the deployment in constrained NSFs. implementation), which benefits the deployment in constrained NSFs.
Moreover, IKEv2 does not need to be performed in gateway-to-gateway Moreover, IKEv2 does not need to be performed in gateway-to-gateway
and host-to-host scenarios under the same Security Controller (see and host-to-host scenarios under the same Security Controller (see
Section 7.1). On the contrary, the overload of creating fresh IPsec Section 7.1). On the contrary, the overload of creating and managing
SAs is shifted to the Security Controller since IKEv2 is not in the IPsec SAs is shifted to the Security Controller since IKEv2 is not in
NSF. As a consequence, this may result in a more complex the NSF. As a consequence, this may result in a more complex
implementation in the controller side. This overload may create some implementation in the controller side in comparison with IKE case.
scalability issues when the number of NSFs is high. 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 Nevertheless, literature around SDN-based network management using a
centralized Security Controller is aware about scalability issues and centralized Security Controller is aware about scalability and
solutions have been already provided (e.g. hierarchical Security performance issues and solutions have been already provided and
Controllers; having multiple replicated Security Controllers, etc). discussed (e.g. hierarchical Security Controllers; having multiple
In the context of SDN-based IPsec management, one straight way to replicated Security Controllers, dedicated high-speed management
reduce the overhead and the potential scalability issue in the networks, etc). In the context of SDN-based IPsec management, one
Security Controller is to apply the IKE case described in this way to reduce the latency and alleviate some performance issues can
document, since the IPsec SAs are managed between NSFs without the be the installation of the IPsec policies and IPsec SAs at the same
involvement of the Security Controller at all, except by the initial time (proactive mode, as described in Section 7.1) instead of waiting
IKE configuration provided by the Security Controller. Other for notifications (e.g. a notification sadb-acquire when a new IPsec
solutions, such as Controller-IKE 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 [I-D.carrel-ipsecme-controller-ike], have proposed that NSFs provide
their DH public keys to the Security Controller, so that the Security their DH public keys to the Security Controller, so that the Security
Controller distributes all public keys to all peers. All peers can Controller distributes all public keys to all peers. All peers can
calculate a unique pairwise secret for each other peer and there is calculate a unique pairwise secret for each other peer and there is
no inter-NSF messages. A rekey mechanism is further described in no inter-NSF messages. A rekey mechanism is further described in
[I-D.carrel-ipsecme-controller-ike]. [I-D.carrel-ipsecme-controller-ike].
In terms of security, IKE case provides better security properties In terms of security, IKE case provides better security properties
than IKE-less case, as we discuss in section Section 9. The main 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 reason is that the NSFs are generating the session keys and not the
skipping to change at page 11, line 5 skipping to change at page 11, line 15
the Security Controller installs first the new inbound SAs in both the Security Controller installs first the new inbound SAs in both
NSFs and then, the outbound IPsec SAs. NSFs and then, the outbound IPsec SAs.
In other words, for the IKE-less case, the Security Controller needs 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 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 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 SA and remove the old one. This rekeying process starts when the
Security Controller receives a sadb-expire notification or it decides Security Controller receives a sadb-expire notification or it decides
so, based on lifetime state data obtained from the NSF. 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 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 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. 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 B. Then, the Security Controller creates an inbound IPsec SA
with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It with SPIa2 in A and another inbound IPsec SA in B with SPIb2. It
can send this information simultaneously to A and B. can send this information simultaneously to A and B.
2. Once the Security Controller receives confirmation from A and B, 2. Once the Security Controller receives confirmation from A and B,
the controller knows that the inbound IPsec A are correctly the controller knows that the inbound IPsec A are correctly
skipping to change at page 11, line 29 skipping to change at page 11, line 40
outbound IPsec SAs: it sends the outbound IPsec SA to A with 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 SPIb2 and the outbound IPsec SA to B with SPIa2. At this point
the new IPsec SAs are ready. the new IPsec SAs are ready.
3. Once the Security Controller receives confirmation from A and B 3. Once the Security Controller receives confirmation from A and B
that the outbound IPsec SAs have been installed, the Security that the outbound IPsec SAs have been installed, the Security
Controller, in parallel, deletes the old IPsec SAs from A Controller, in parallel, deletes the old IPsec SAs from A
(inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and (inbound SPIa1 and outbound SPIb1) and B (outbound SPIa1 and
inbound SPIb1). 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. 5.3.2. NSF state loss.
If one of the NSF restarts, it will lose the IPsec state (affected If one of the NSF restarts, it will lose the IPsec state (affected
NSF). By default, the Security Controller can assume that all the 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 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 PAD information to the NSF in the IKE case, and SPD and SAD
information in IKE-less case. information in IKE-less case.
In both cases, the Security Controller is aware of the affected NSF 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 (e.g. the NETCONF/TCP connection is broken with the affected NSF, the
skipping to change at page 15, line 36 skipping to change at page 16, line 20
| | +--rw processing-info | | +--rw processing-info
| | | +--rw action? ipsec-spd-action | | | +--rw action? ipsec-spd-action
| | | +--rw ipsec-sa-cfg | | | +--rw ipsec-sa-cfg
| | | +--rw pfp-flag? boolean | | | +--rw pfp-flag? boolean
| | | +--rw ext-seq-num? boolean | | | +--rw ext-seq-num? boolean
| | | +--rw seq-overflow? boolean | | | +--rw seq-overflow? boolean
| | | +--rw stateful-frag-check? boolean | | | +--rw stateful-frag-check? boolean
| | | +--rw mode? ipsec-mode | | | +--rw mode? ipsec-mode
| | | +--rw protocol-parameters? ipsec-protocol-parameters | | | +--rw protocol-parameters? ipsec-protocol-parameters
| | | +--rw esp-algorithms | | | +--rw esp-algorithms
| | | | +--rw integrity* integrity-algorithm-type | | | | +--rw integrity* integrity-algorithm-type
| | | | +--rw encryption* encryption-algorithm-type | | | | +--rw encryption* encryption-algorithm-type
| | | | +--rw tfc-pad? boolean | | | | +--rw tfc-pad? boolean
| | | +--rw tunnel | | | +--rw tunnel
| | | +--rw local inet:ip-address | | | +--rw local inet:ip-address
| | | +--rw remote inet:ip-address | | | +--rw remote inet:ip-address
| | | +--rw df-bit? enumeration | | | +--rw df-bit? enumeration
| | | +--rw bypass-dscp? boolean | | | +--rw bypass-dscp? boolean
| | | +--rw dscp-mapping? yang:hex-string | | | +--rw dscp-mapping? yang:hex-string
| | | +--rw ecn? boolean | | | +--rw ecn? boolean
| | +--rw spd-mark | | +--rw spd-mark
skipping to change at page 20, line 31 skipping to change at page 21, line 19
Security. Pol. | |IPsec Policies| | | | Security. Pol. | |IPsec Policies| | | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | | | | | |
| | | | | | | |
+--------------------------|-----|-------+ +--------------------------|-----|-------+
| | | |
| (3) | | (3) |
|-------------------------+ +---| |-------------------------+ +---|
V V V V
+----------------------+ +----------------------+ +----------------------+ +----------------------+
| NSF1 |<=======>| NSF2 | | NSF A |<=======>| NSF B |
|IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) | |IKEv2/IPsec(SPD/PAD) |
+----------------------+ (4) +----------------------+ +----------------------+ (4) +----------------------+
Figure 3: Host-to-host / gateway-to-gateway single Security Figure 3: Host-to-host / gateway-to-gateway single Security
Controller for the IKE case. Controller for the IKE case.
Figure 3 describes the IKE case: Figure 3 describes the IKE case:
1. The administrator defines general flow-based security policies. 1. The administrator defines general flow-based security policies.
The Security Controller looks for the NSFs involved (NSF1 and The Security Controller looks for the NSFs involved (NSF A and
NSF2). NSF B).
2. The Security Controller generates IKEv2 credentials for them and 2. The Security Controller generates IKEv2 credentials for them and
translates the policies into SPD and PAD entries. translates the policies into SPD and PAD entries.
3. The Security Controller inserts an IKEv2 configuration that 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 4. If the previous step is successful, the flow is protected by
IKEv2. means of the IPsec SA established with IKEv2.
+----------------------------------------+ +----------------------------------------+
| (1) Security Controller | | (1) Security Controller |
Flow-based | | Flow-based | |
Security -----------| | Security -----------| |
Policy | V | Policy | V |
| +---------------+ (2)+-------------+ | | +---------------+ (2)+-------------+ |
| |Translate into |--->| South. Prot.| | | |Translate into |--->| South. Prot.| |
| |IPsec policies | | | | | |IPsec policies | | | |
| +---------------+ +-------------+ | | +---------------+ +-------------+ |
| | | | | | | |
| | | | | | | |
+-------------------------| --- |--------+ +-------------------------| --- |--------+
| | | |
| (3) | | (3) |
|----------------------+ +--| |----------------------+ +--|
V V V V
+------------------+ +------------------+ +------------------+ +------------------+
| NSF1 |<=====>| NSF2 | | NSF A |<=====>| NSF B |
|IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) | |IPsec(SPD/SAD) | 4) |IPsec(SPD/SAD) |
+------------------+ +------------------+ +------------------+ +------------------+
Figure 4: Host-to-host / gateway-to-gateway single Security Figure 4: Host-to-host / gateway-to-gateway single Security
Controller for IKE-less case. Controller for IKE-less case.
In the IKE-less case, flow-based security policies defined by the In the IKE-less case, flow-based security policies defined by the
administrator are translated into IPsec SPD entries and inserted into administrator are translated into IPsec SPD entries and inserted into
the corresponding NSFs. Besides, fresh SAD entries will be also the corresponding NSFs. Besides, fresh SAD entries will be also
generated by the Security Controller and enforced in the NSFs. In generated by the Security Controller and enforced in the NSFs. In
this case, the Security Controller does not run any IKEv2 this case, the Security Controller does not run any IKEv2
implementation (neither the NSFs), and it provides the cryptographic implementation (neither the NSFs), and it provides the cryptographic
material for the IPsec SAs. These keys will be also distributed material for the IPsec SAs. These keys will be also distributed
securely through the southbound interface. Note that this is securely through the southbound interface. Note that this is
possible because both NSFs are managed by the same Security possible because both NSFs are managed by the same Security
Controller. Controller.
Figure 4 describes the IKE-less case, when a data packet needs to be 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, 1. The administrator establishes the flow-based security policies,
and the Security Controller looks for the involved NSFs. and the Security Controller looks for the involved NSFs.
2. The Security Controller translates the flow-based security 2. The Security Controller translates the flow-based security
policies into IPsec SPD and SAD entries. policies into IPsec SPD and SAD entries.
3. The Security Controller inserts these entries in both NSF1 and 3. The Security Controller inserts these entries in both NSF A and
NSF2 IPsec databases. It associates a lifetime to the IPsec SAs. NSF B IPsec databases (SPD and SAD). The following text
When this lifetime expires, the NSF will send a sadb-expire describes how this happens between two NSFs A and B:
notification to the Security Controller in order to start the
rekeying process. * 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 4. The flow is protected with the IPsec SA established by the
Security Controller. Security Controller.
It is also possible that the Security Controller only installs the Instead of installing IPsec policies in the SPD and IPsec SAs in the
SPD entries in step 2. In such a case, when a data packet requires SAD in step 3 (proactive mode), it is also possible that the Security
to be protected with IPsec, the NSF that saw first the data packet Controller only installs the SPD entries in step 3 (reactive mode).
will send a sadb-acquire notification that informs the Security In such a case, when a data packet requires to be protected with
Controller that SAD entries with the IPsec SAs required to process IPsec, the NSF that saw first the data packet will send a sadb-
the data packet needs to be installed in the NSFs. 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 Both NSFs could be two hosts that exchange traffic and require to
establish an end-to-end security association to protect their establish an end-to-end security association to protect their
communications (host-to-host) or two gateways (gateway-to-gateway), communications (host-to-host) or two gateways (gateway-to-gateway),
for example, within an enterprise that needs to protect the traffic for example, within an enterprise that needs to protect the traffic
between the networks of two branch offices. between the networks of two branch offices.
Applicability of these configurations appear in current and new Applicability of these configurations appear in current and new
networking scenarios. For example, SD-WAN technologies are providing networking scenarios. For example, SD-WAN technologies are providing
dynamic and on-demand VPN connections between branch offices, or dynamic and on-demand VPN connections between branch offices, or
skipping to change at page 22, line 48 skipping to change at page 24, line 39
associations in a centralized point with an abstracted view of associations in a centralized point with an abstracted view of
the network. the network.
2. Any NSF deployed in the system does not need manual 2. Any NSF deployed in the system does not need manual
configuration, therefore allowing its deployment in an automated configuration, therefore allowing its deployment in an automated
manner. manner.
7.2. Host-to-host or gateway-to-gateway under different Security 7.2. Host-to-host or gateway-to-gateway under different Security
Controllers Controllers
It is also possible that two NSFs (i.e. NSF1 and NSF2) are under the It is also possible that two NSFs (i.e. NSF A and NSF B) are under
control of two different Security Controllers. This may happen, for the control of two different Security Controllers. This may happen,
example, when two organizations, namely Enterprise A and Enterprise for example, when two organizations, namely Enterprise A and
B, have their headquarters interconnected through a WAN connection Enterprise B, have their headquarters interconnected through a WAN
and they both have deployed a SDN-based architecture to provide connection and they both have deployed a SDN-based architecture to
connectivity to all their clients. provide connectivity to all their clients.
+-------------+ +-------------+ +-------------+ +-------------+
| | | | | | | |
Flow-based| Security |<=========>| Security <--Flow-based Flow-based| Security |<=========>| Security <--Flow-based
Sec. Pol.--> Controller | (3) | Controller | Sec. Pol. Sec. Pol.--> Controller | (3) | Controller | Sec. Pol.
(1) | A | | B | (2) (1) | A | | B | (2)
+-------------+ +-------------+ +-------------+ +-------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+--------------------+ +--------------------+ +--------------------+ +--------------------+
| NSF1 |<========>| NSF2 | | NSF A |<=======>| NSF B |
|IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)| |IKEv2/IPsec(SPD/PAD)|
+--------------------+ (5) +--------------------+ +--------------------+ (5) +--------------------+
Figure 5: Different Security Controllers in the IKE case. Figure 5: Different Security Controllers in the IKE case.
Figure 5 describes IKE case when two Security Controllers are Figure 5 describes IKE case when two Security Controllers are
involved in the process. involved in the process.
1. The A's administrator establishes general Flow-based Security 1. The A's administrator establishes general Flow-based Security
Policies in Security Controller A. Policies in Security Controller A.
2. The B's administrator establishes general Flow-based Security 2. The B's administrator establishes general Flow-based Security
Policies in Security Controller B. Policies in Security Controller B.
3. The Security Controller A realizes that protection is required 3. The Security Controller A realizes that protection is required
between the NSF1 and NSF2, but the NSF2 is under the control of between the NSF A and NSF B, but the NSF B is under the control
another Security Controller (Security Controller B), so it starts of another Security Controller (Security Controller B), so it
negotiations with the other controller to agree on the IPsec SPD starts negotiations with the other controller to agree on the
policies and IKEv2 credentials for their respective NSFs. NOTE: IPsec SPD policies and IKEv2 credentials for their respective
This may require extensions in the East/West interface. NSFs. NOTE: This may require extensions in the East/West
interface.
4. Then, both Security Controllers enforce the IKEv2 credentials, 4. Then, both Security Controllers enforce the IKEv2 credentials,
related parameters and the SPD and PAD entries in their related parameters and the SPD and PAD entries in their
respective NSFs. respective NSFs.
5. The flow is protected with the IPsec SAs established with IKEv2 5. The flow is protected with the IPsec SAs established with IKEv2
between both NSFs. between both NSFs.
+--------------+ +--------------+ +--------------+ +--------------+
| | | | | | | |
Flow-based. ---> | | <---Flow-based Flow-based. ---> | | <---Flow-based
Prot. | Security |<===========>| Security |Sec. Prot. | Security |<===========>| Security |Sec.
Pol.(1)| Controller | (3) | Controller |Pol. (2) Pol.(1)| Controller | (3) | Controller |Pol. (2)
| A | | B | | A | | B |
+--------------+ +--------------+ +--------------+ +--------------+
| | | |
| (4) (4) | | (4) (4) |
V V V V
+--------------+ (5) +--------------+ +--------------+ (5) +--------------+
| NSF1 |<==============>| NSF2 | | NSF A |<==============>| NSF B |
|IPsec(SPD/SAD)| |IPsec(SPD/SAD)| |IPsec(SPD/SAD)| |IPsec(SPD/SAD)|
+--------------+ +--------------+ +--------------+ +--------------+
Figure 6: Different Security Controllers in the IKE-less case. Figure 6: Different Security Controllers in the IKE-less case.
Figure 6 describes IKE-less case when two Security Controllers are Figure 6 describes IKE-less case when two Security Controllers are
involved in the process. involved in the process.
1. The A's administrator establishes general Flow Protection 1. The A's administrator establishes general Flow Protection
Policies in Security Controller A. Policies in Security Controller A.
2. The B's administrator establishes general Flow Protection 2. The B's administrator establishes general Flow Protection
Policies in Security Controller B. Policies in Security Controller B.
3. The Security Controller A realizes that the flow between NSF1 and 3. The Security Controller A realizes that the flow between NSF B
NSF2 MUST be protected. Nevertheless, it notices that NSF2 is and NSF B MUST be protected. Nevertheless, it notices that NSF B
under the control of another Security Controller B, so it starts is under the control of another Security Controller B, so it
negotiations with the other controller to agree on the IPsec SPD starts negotiations with the other controller to agree on the
and SAD entries that define the IPsec SAs. NOTE: It would worth IPsec SPD and SAD entries that define the IPsec SAs. NOTE: It
evaluating IKEv2 as the protocol for the East/West interface in would worth evaluating IKEv2 as the protocol for the East/West
this case. interface in this case.
4. Once the Security Controllers have agreed on the key material and 4. Once the Security Controllers have agreed on the key material and
the details of the IPsec SAs, they both enforce this information the details of the IPsec SAs, they both enforce this information
into their respective NSFs. into their respective NSFs.
5. The flow is protected with the IPsec SAs established by both 5. The flow is protected with the IPsec SAs established by both
Security Controllers in their respective NSFs. Security Controllers in their respective NSFs.
8. IANA Considerations 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 9. Security Considerations
First of all, this document shares all the security issues of SDN First of all, this document shares all the security issues of SDN
that are specified in the "Security Considerations" section of that are specified in the "Security Considerations" section of
[ITU-T.Y.3300] and [RFC8192]. [ITU-T.Y.3300] and [RFC8192].
On the one hand, it is important to note that there MUST exit a On the one hand, it is important to note that there MUST exit a
security association between the Security Controller and the NSFs to security association between the Security Controller and the NSFs to
protect of the critical information (cryptographic keys, protect of the critical information (cryptographic keys,
skipping to change at page 26, line 41 skipping to change at page 29, line 24
that it MUST NOT store the keys after distributing them. Moreover, that it MUST NOT store the keys after distributing them. Moreover,
the NSFs receiving private key material MUST NOT allow the reading of the NSFs receiving private key material MUST NOT allow the reading of
these values by any other entity (including the Security Controller these values by any other entity (including the Security Controller
itself) once they have been applied (i.e. write only operations) into itself) once they have been applied (i.e. write only operations) into
the NSFs. Nevertheless, if the attacker has access to the Security the NSFs. Nevertheless, if the attacker has access to the Security
Controller during the period of time that key material is generated, Controller during the period of time that key material is generated,
it may obtain these values. In other words, the attacker might be 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- able to observe the IPsec traffic and decrypt, or even modify and re-
encrypt the traffic between peers. 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 10. Acknowledgements
Authors want to thank Paul Wouters, Sowmini Varadhan, David Carrel, Authors want to thank Paul Wouters, Valery Smyslov, Sowmini Varadhan,
Yoav Nir, Tero Kivinen, Graham Bartlett, Sandeep Kampati, Linda David Carrel, Yoav Nir, Tero Kivinen, Martin Bjorklund, Graham
Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Alejandro Abad- Bartlett, Sandeep Kampati, Linda Dunbar, Carlos J. Bernardos,
Carrascosa, Ignacio Martinez and Ruben Ricart for their valuable Alejandro Perez-Mendez, Alejandro Abad-Carrascosa, Ignacio Martinez
comments. and Ruben Ricart for their valuable comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[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>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "Interface to Network Security Functions and J. Jeong, "Interface to Network Security Functions
(I2NSF): Problem Statement and Use Cases", RFC 8192, (I2NSF): Problem Statement and Use Cases", RFC 8192,
DOI 10.17487/RFC8192, July 2017, DOI 10.17487/RFC8192, July 2017,
<https://www.rfc-editor.org/info/rfc8192>. <https://www.rfc-editor.org/info/rfc8192>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References 11.2. Informative References
[I-D.carrel-ipsecme-controller-ike] [I-D.carrel-ipsecme-controller-ike]
Carrel, D. and B. Weiss, "IPsec Key Exchange using a Carrel, D. and B. Weiss, "IPsec Key Exchange using a
Controller", draft-carrel-ipsecme-controller-ike-01 (work Controller", draft-carrel-ipsecme-controller-ike-01 (work
in progress), March 2019. in progress), March 2019.
[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)
skipping to change at page 28, line 35 skipping to change at page 33, line 27
October 2013. October 2013.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
"SDN Architecture", June 2014. "SDN Architecture", June 2014.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, Management API, Version 2", RFC 2367,
DOI 10.17487/RFC2367, July 1998, DOI 10.17487/RFC2367, July 1998,
<https://www.rfc-editor.org/info/rfc2367>. <https://www.rfc-editor.org/info/rfc2367>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>. <https://www.rfc-editor.org/info/rfc6071>.
skipping to change at page 31, line 16 skipping to change at page 36, line 16
(RFC 2119) (RFC 8174) when, and only when, they appear (RFC 2119) (RFC 8174) when, and only when, they appear
in all capitals, as shown here."; in all capitals, as shown here.";
revision "2019-07-07" { revision "2019-07-07" {
description "Revision 05"; description "Revision 05";
reference "RFC XXXX: YANG Groupings and typedef reference "RFC XXXX: YANG Groupings and typedef
for IKE and IKE-less case"; for IKE and IKE-less case";
} }
typedef encryption-algorithm-type { typedef encryption-algorithm-type {
type uint32; type uint16;
description 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 number extracted from IANA Registry. The acceptable
values MUST follow the requirement levels for values MUST follow the requirement levels for
encryption algorithms for ESP and IKEv2."; encryption algorithms for ESP and IKEv2.";
reference reference
"IANA Registry- Transform Type 1 - Encryption "IANA Registry- Transform Type 1 - Encryption
Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP) Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 - and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage Algorithm Implementation Requirements and Usage
Guidance for the Internet Key Exchange Protocol Guidance for the Internet Key Exchange Protocol
Version 2 (IKEv2)."; Version 2 (IKEv2).";
} }
typedef integrity-algorithm-type { typedef integrity-algorithm-type {
type uint32; type uint16;
description description
"The integrity algorithm is specified with a 32-bit "The integrity algorithm is specified with a 16-bit
number extracted from IANA Registry. number extracted from IANA Registry.
The acceptable values MUST follow the requirement The acceptable values MUST follow the requirement
levels for encryption algorithms for ESP and IKEv2."; levels for encryption algorithms for ESP and IKEv2.";
reference reference
"IANA Registry- Transform Type 3 - Integrity "IANA Registry- Transform Type 3 - Integrity
Algorithm Transform IDs. RFC 8221 - Cryptographic Algorithm Transform IDs. RFC 8221 - Cryptographic
Algorithm Implementation Requirements and Usage Algorithm Implementation Requirements and Usage
Guidance for Encapsulating Security Payload (ESP) Guidance for Encapsulating Security Payload (ESP)
and Authentication Header (AH) and RFC 8247 - and Authentication Header (AH) and RFC 8247 -
Algorithm Implementation Requirements and Usage Algorithm Implementation Requirements and Usage
skipping to change at page 38, line 51 skipping to change at page 43, line 51
reference reference
"Section 4.4.2.1. in RFC 4301."; "Section 4.4.2.1. in RFC 4301.";
} }
leaf ecn { leaf ecn {
type boolean; type boolean;
default false; default false;
description description
"Explicit Congestion Notification (ECN). If true "Explicit Congestion Notification (ECN). If true
copy CE bits to inner header."; copy CE bits to inner header.";
reference reference
"Section 5.2.1 and Annex C in RFC 4301."; "Section 5.1.2 and Annex C in RFC 4301.";
} }
} }
grouping selector-grouping { grouping selector-grouping {
description description
"This grouping contains the definition of a Traffic "This grouping contains the definition of a Traffic
Selector, which is used in the IPsec policies and Selector, which is used in the IPsec policies and
IPsec SAs."; IPsec SAs.";
skipping to change at page 46, line 26 skipping to change at page 51, line 26
immediately without waiting any packet."; immediately without waiting any packet.";
} }
} }
description description
"Different policies to set IPsec SA configuration "Different policies to set IPsec SA configuration
into NSF's kernel when IKEv2 implementation has into NSF's kernel when IKEv2 implementation has
started."; started.";
} }
typedef pfs-group { typedef pfs-group {
type uint32; type uint16;
description description
"DH groups for IKE and IPsec SA rekey."; "DH groups for IKE and IPsec SA rekey.";
reference reference
"Section 3.3.2 in RFC 7296. Transform Type 4 - "Section 3.3.2 in RFC 7296. Transform Type 4 -
Diffie-Hellman Group Transform IDs in IANA Registry Diffie-Hellman Group Transform IDs in IANA Registry
- Internet Key Exchange Version 2 (IKEv2) - Internet Key Exchange Version 2 (IKEv2)
Parameters."; Parameters.";
} }
typedef auth-protocol-type { typedef auth-protocol-type {
skipping to change at page 59, line 8 skipping to change at page 64, line 8
"This container carries the "This container carries the
configuration of a IPsec policy."; configuration of a IPsec policy.";
uses ic:ipsec-policy-grouping; uses ic:ipsec-policy-grouping;
} }
description description
"List of entries which will constitute "List of entries which will constitute
the representation of the SPD. Since we the representation of the SPD. Since we
have IKE in this case, it is only have IKE in this case, it is only
required to send a IPsec policy from required to send a IPsec policy from
this NSF where 'local' is this NSF and this NSF where 'local' is this NSF and
remote the other NSF. The IKE 'remote' the other NSF. The IKE
implementation will install IPsec implementation will install IPsec
policies in the NSF's kernel in both policies in the NSF's kernel in both
directions (inbound and outbound) and directions (inbound and outbound) and
their corresponding IPsec SAs based on their corresponding IPsec SAs based on
the information in this SPD entry."; the information in this SPD entry.";
} }
reference reference
"Section 2.9 in RFC 7296."; "Section 2.9 in RFC 7296.";
} }
container child-sa-info { container child-sa-info {
 End of changes. 44 change blocks. 
95 lines changed or deleted 314 lines changed or added

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