draft-ietf-i2nsf-sdn-ipsec-flow-protection-02.txt   draft-ietf-i2nsf-sdn-ipsec-flow-protection-03.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 3, 2019 July 2, 2018 Expires: April 25, 2019 October 22, 2018
Software-Defined Networking (SDN)-based IPsec Flow Protection Software-Defined Networking (SDN)-based IPsec Flow Protection
draft-ietf-i2nsf-sdn-ipsec-flow-protection-02 draft-ietf-i2nsf-sdn-ipsec-flow-protection-03
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 44 skipping to change at page 1, line 44
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 3, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 5.3.3. NAT Traversal . . . . . . . . . . . . . . . . . . . . 10
6. YANG configuration data models . . . . . . . . . . . . . . . 11 6. YANG configuration data models . . . . . . . . . . . . . . . 11
6.1. Security Policy Database (SPD) Model . . . . . . . . . . 11 6.1. Security Policy Database (SPD) Model . . . . . . . . . . 11
6.2. Security Association Database (SAD) Model . . . . . . . . 13 6.2. Security Association Database (SAD) Model . . . . . . . . 13
6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 16 6.3. Peer Authorization Database (PAD) Model . . . . . . . . . 16
6.4. Internet Key Exchange (IKEv2) Model . . . . . . . . . . . 17 6.4. Internet Key Exchange (IKEv2) Model . . . . . . . . . . . 17
7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 19 7. Use cases examples . . . . . . . . . . . . . . . . . . . . . 19
7.1. Host-to-Host or Gateway-to-gateway under the same 7.1. Host-to-Host or Gateway-to-gateway under the same
controller . . . . . . . . . . . . . . . . . . . . . . . 19 controller . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Host-to-Host or Gateway-to-gateway under different 7.2. Host-to-Host or Gateway-to-gateway under different
Security controllers . . . . . . . . . . . . . . . . . . 21 Security controllers . . . . . . . . . . . . . . . . . . 22
8. Implementation notes . . . . . . . . . . . . . . . . . . . . 23 8. Implementation notes . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Appendix A: YANG model IPsec Configuration data . . 29 Appendix A. Appendix A: YANG model IPsec Configuration data . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Software-Defined Networking (SDN) is an architecture that enables Software-Defined Networking (SDN) is an architecture that enables
users to directly program, orchestrate, control and manage network users to directly program, orchestrate, control and manage network
resources through software. SDN paradigm relocates the control of resources through software. SDN paradigm relocates the control of
network resources to a dedicated network element, namely SDN network resources to a dedicated network element, namely SDN
controller. The SDN controller manages and configures the controller. The SDN controller manages and configures the
distributed network resources and provides an abstracted view of the distributed network resources and provides an abstracted view of the
network resources to the SDN applications. The SDN application can network resources to the SDN applications. The SDN application can
skipping to change at page 18, line 4 skipping to change at page 18, line 4
The model related to IKEv2 has been extracted from reading IKEv2 The model related to IKEv2 has been extracted from reading IKEv2
standard in [RFC7296], and observing some open source standard in [RFC7296], and observing some open source
implementations, such as Strongswan or Libreswan. implementations, such as Strongswan or Libreswan.
+--rw ikev2 {case1}? +--rw ikev2 {case1}?
| +--rw ike-connection | +--rw ike-connection
| | +--rw ike-conn-entries* [conn-name] | | +--rw ike-conn-entries* [conn-name]
| | +--rw conn-name string | | +--rw conn-name string
| | +--rw autostartup type-autostartup | | +--rw autostartup type-autostartup
| | +--rw nat-traversal? boolean | | +--rw nat-traversal? boolean
| | +--rw initial-contact? boolean
| | +--rw encap | | +--rw encap
| | | +--rw espencap? esp-encap | | | +--rw espencap? esp-encap
| | | +--rw sport? inet:port-number | | | +--rw sport? inet:port-number
| | | +--rw dport? inet:port-number | | | +--rw dport? inet:port-number
| | | +--rw oaddr? inet:ip-address | | | +--rw oaddr? inet:ip-address
| | +--rw version? enumeration | | +--rw version? enumeration
| | +--rw phase1-lifetime uint32 | | +--rw phase1-lifetime uint32
| | +--rw phase1-authalg* integrity-algorithm-t | | +--rw phase1-authalg* integrity-algorithm-t
| | +--rw phase1-encalg* encryption-algorithm-t | | +--rw phase1-encalg* encryption-algorithm-t
| | +--rw combined-enc-intr? boolean | | +--rw combined-enc-intr? boolean
skipping to change at page 18, line 42 skipping to change at page 18, line 43
| | | | +--:(ipv6) | | | | +--:(ipv6)
| | | | | +--rw ipv6? inet:ipv6-address | | | | | +--rw ipv6? inet:ipv6-address
| | | | +--:(fqdn) | | | | +--:(fqdn)
| | | | | +--rw fqdn? inet:domain-name | | | | | +--rw fqdn? inet:domain-name
| | | | +--:(dn) | | | | +--:(dn)
| | | | | +--rw dn? string | | | | | +--rw dn? string
| | | | +--:(user_fqdn) | | | | +--:(user_fqdn)
| | | | +--rw user_fqdn? string | | | | +--rw user_fqdn? string
| | | +--rw my-identifier string | | | +--rw my-identifier string
| | +--rw pfs_group* uint32 | | +--rw pfs_group* uint32
| | +--rw ipsec-sad-lifetime-hard
| | | +--rw added? uint64
| | | +--rw used? uint64
| | | +--rw bytes? uint32
| | | +--rw packets? uint32
| | | +--rw action? lifetime-action
| | +--rw ipsec-sad-lifetime-soft
| | | +--rw added? uint64
| | | +--rw used? uint64
| | | +--rw bytes? uint32
| | | +--rw packets? uint32
| | | +--rw action? lifetime-action
| | +--ro ike-stats | | +--ro ike-stats
| | +--ro uptime | | +--ro uptime
| | | +--ro running? yang:date-and-time | | | +--ro running? yang:date-and-time
| | | +--ro since? yang:date-and-time | | | +--ro since? yang:date-and-time
| | +--ro initiator? boolean | | +--ro initiator? boolean
| | +--ro initiator-spi? uint64 | | +--ro initiator-spi? uint64
| | +--ro responder-spi? uint64 | | +--ro responder-spi? uint64
| | +--ro nat-local? boolean | | +--ro nat-local? boolean
| | +--ro nat-remote? boolean | | +--ro nat-remote? boolean
| | +--ro nat-any? boolean | | +--ro nat-any? boolean
skipping to change at page 24, line 37 skipping to change at page 25, line 37
To allow the NETCONF server implementation interacts with the IKE To allow the NETCONF server implementation interacts with the IKE
daemon, we have used the Versatile IKE Configuration Interface (VICI) daemon, we have used the Versatile IKE Configuration Interface (VICI)
in Strongswan. This allows changes in the IKE part of the in Strongswan. This allows changes in the IKE part of the
configuration data to be applied in the IKE daemon dynamically. configuration data to be applied in the IKE daemon dynamically.
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]. We have divided this section in two [ITU-T.Y.3300] and [RFC8192]. On the one hand, it is important to
parts to analyze different security considerations for both cases: note that there must exit a security association between the Security
NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2). In general, Controller and the NSFs to protect of the critical information
the Security Controller, as typically in the SDN paradigm, is a (cryptographic keys, configuration parameter, etc...) exchanged
target for different type of attacks. As a consequence, the Security between these entities. For example, if NETCONF is used as
Controller is a key entity in the infrastructure and MUST be southbound protocol between the Security Controller and the NSFs, it
protected accordingly. In particular, according to this document, is defined that TLS or SSH security assocation must be established
the Security Controller will handle cryptographic material so that between both entities. On the other hand, we have divided this
the attacker may try to access this information. Although, we can section in two parts to analyze different security considerations for
assume this attack will not likely to happen due to the assumed both cases: NSF with IKEv2 (case 1) and NSF without IKEv2 (case 2).
security measurements to protect the Security Controller, it deserves In general, the Security Controller, as typically in the SDN
some analysis in the hypothetical the attack occurs. The impact is paradigm, is a target for different type of attacks. As a
different depending on the case 1 or case 2. consequence, the Security Controller is a key entity in the
infrastructure and MUST be protected accordingly. In particular,
according to this document, the Security Controller will handle
cryptographic material so that the attacker may try to access this
information. Although, we can assume this attack will not likely to
happen due to the assumed security measurements to protect the
Security Controller, it deserves some analysis in the hypothetical
the attack occurs. The impact is different depending on the case 1
or case 2.
9.1. Case 1 9.1. Case 1
In this case 1, the Security Controller sends IKE credentials (PSK, In this case 1, the Security Controller sends IKE credentials (PSK,
public/private keys, certificates, etc...) to the NSFs. The general public/private keys, certificates, etc...) to the NSFs using the
recommendation is that the Security Controller NEVER stores the IKE security association between Security Controller and NSFs. The
credentials after distributing them. Moreover the NSFs MUST NOT general recommendation is that the Security Controller SHOULD NEVER
allow the reading of these values once they have been applied by the store the IKE credentials after distributing them. Moreover the NSFs
Security Controller (i.e. write only operations). If the attacker MUST NOT allow the reading of these values once they have been
has access to the Security Controller during the period of time that applied by the Security Controller (i.e. write only operations). If
key material is generated, it may access to these values. Since the attacker has access to the Security Controller during the period
these values are used during NSF authentication in IKEv2, it may of time that key material is generated, it may access to these
impersonate the affected NSFs. Several recommendations are values. Since these values are used during NSF authentication in
important. If PSK authentication is used in IKEv2 is used, IKEv2, it may impersonate the affected NSFs. Several recommendations
immediately after generating and distributing it, the Security are important. If PSK authentication is used in IKEv2, the Security
Controller should remove it. If raw public keys are used, the Controller SHOULD remove the PSK immediately after generating and
Security Controller should remove the associate private key distributing it. If raw public keys are used, the Security
immediately after generating and distributing them to the NSFs. If Controller SHOULD remove the associated private key immediately after
certificates are used, the NSF may generate the private key and generating and distributing them to the NSFs. If certificates are
exports the public key for certification in the Security Controller. used, the NSF may generate the private key and exports the public key
for certification in the Security Controller.
9.2. Case 2 9.2. Case 2
In the case 2, the controller sends the IPsec SA information to the In the case 2, the controller sends the IPsec SA information to the
SAD that includes the keys for integrity and encryption (when ESP is SAD that includes the keys for integrity and encryption (when ESP is
used). That key material are symmetric keys to protect data traffic. used). That key material are symmetric keys to protect data traffic.
The general recommendation is that the Security Controller NEVER The general recommendation is that the Security Controller SHOULD
stores the keys after distributing them. Moreover the NSFs MUST NOT NEVER stores the keys after distributing them. Moreover the NSFs
allow the reading of these values once they have been applied by the MUST NOT allow the reading of these values once they have been
Security Controller (i.e. write only operations). Nevertheless, if applied by the Security Controller (i.e. write only operations).
the attacker has access to the Security Controller during the period Nevertheless, if the attacker has access to the Security Controller
of time that key material is generated, it may access to these during the period of time that key material is generated, it may
values. In other words, it may have access to the key material used access to these values. In other words, it may have access to the
in the distributed IPsec SAs and observe the traffic between peers. key material used in the distributed IPsec SAs and observe the
traffic between peers. In any case, some escenarios with special
secure enviroments (e.g. physically isolated data centers) make this
type of attack difficult. Moreover, some scenarios such as IoT
networks with constrained devices, where reducing implementation and
computation overhead is important, can apply case 2 as a tradeoff
between security and low overhead at the constrained device, at the
cost of assuming the security impact described above.
10. Acknowledgements 10. Acknowledgements
Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero Authors want to thank Sowmini Varadhan, David Carrel, Yoav Nir, Tero
Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda Kivinen, Paul Wouters, Graham Bartlett, Sandeep Kampati, Linda
Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando Dunbar, Carlos J. Bernardos, Alejandro Perez-Mendez, Fernando
Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and Pereniguez-Garcia, Alejandro Abad-Carrascosa, Ignacio Martinez and
Ruben Ricart for their valuable comments. Ruben Ricart for their valuable comments.
11. References 11. References
skipping to change at page 26, line 42 skipping to change at page 28, line 8
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
and J. Jeong, "I2NSF Problem Statement and Use cases", and J. Jeong, "I2NSF Problem Statement and Use cases",
draft-ietf-i2nsf-problem-and-use-cases-16 (work in draft-ietf-i2nsf-problem-and-use-cases-16 (work in
progress), May 2017. progress), May 2017.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-05 (work in Terminology", draft-ietf-i2nsf-terminology-06 (work in
progress), January 2018. progress), July 2018.
[I-D.jeong-i2nsf-sdn-security-services-05] [I-D.jeong-i2nsf-sdn-security-services-05]
Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee, Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
"Software-Defined Networking Based Security Services using "Software-Defined Networking Based Security Services using
Interface to Network Security Functions", draft-jeong- Interface to Network Security Functions", draft-jeong-
i2nsf-sdn-security-services-05 (work in progress), July i2nsf-sdn-security-services-05 (work in progress), July
2016. 2016.
[I-D.pfkey-spd] [I-D.pfkey-spd]
Sakane, S., "PF_KEY Extensions for IPsec Policy Management Sakane, S., "PF_KEY Extensions for IPsec Policy Management
skipping to change at page 29, line 7 skipping to change at page 30, line 7
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[strongswan] [strongswan]
CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based CESNET, CESNET., "StrongSwan: the OpenSource IPsec-based
VPN Solution", April 2017. VPN Solution", April 2017.
Appendix A. Appendix A: YANG model IPsec Configuration data Appendix A. Appendix A: YANG model IPsec Configuration data
<CODE BEGINS> file "ietf-ipsec@2018-06-29.yang" <CODE BEGINS> file "ietf-ipsec@2018-10-20.yang"
module ietf-ipsec { module ietf-ipsec {
namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec"; namespace "urn:ietf:params:xml:ns:yang:ietf-ipsec";
prefix "eipsec"; prefix "eipsec";
import ietf-inet-types { prefix inet; } import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
organization "University of Murcia"; organization "University of Murcia";
skipping to change at page 29, line 37 skipping to change at page 30, line 37
Gabriel Lopez Millan Gabriel Lopez Millan
Dept. Information and Communications Engineering (DIIC) Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia Faculty of Computer Science-University of Murcia
30100 Murcia - Spain 30100 Murcia - Spain
Tel: +34 868888504 Tel: +34 868888504
email: gabilm@um.es email: gabilm@um.es
"; ";
description "Data model for IPSec"; description "Data model for IPSec";
revision "2018-06-29" { revision "2018-10-20" {
description description
"Revision"; "Revision";
reference ""; reference "";
} }
feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs feature case1 { description "feature case 1: IKE SPD PAD"; } // IKE/IPSec in the NSFs
feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs feature case2 { description "feature case 2: SPD SAD"; } // Only IPSec in the NSFs
typedef encryption-algorithm-t { typedef encryption-algorithm-t {
skipping to change at page 40, line 51 skipping to change at page 41, line 51
leaf phase1-lifetime { type uint32; mandatory true; description "lifetime for IKE Phase 1 SAs";} leaf phase1-lifetime { type uint32; mandatory true; description "lifetime for IKE Phase 1 SAs";}
leaf-list phase1-authalg { type integrity-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";} leaf-list phase1-authalg { type integrity-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";}
leaf-list phase1-encalg { type encryption-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";} leaf-list phase1-encalg { type encryption-algorithm-t; description "Auth algorigthm for IKE Phase 1 SAs";}
leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";} leaf combined-enc-intr { type boolean; description "Combined mode algorithms (encryption and integrity).";}
leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";} leaf dh_group { type uint32; mandatory true; description "Group number for Diffie Hellman Exponentiation";}
} /* list isakmp-proposal */ } /* list isakmp-proposal */
grouping phase2-info { grouping phase2-info {
description "IKE Phase 2 Information"; description "IKE Phase 2 Information";
leaf-list pfs_group { type uint32; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; } leaf-list pfs_group { type uint32; description "If non-zero, require perfect forward secrecy when requesting new SA. The non-zero value is the required group number"; }
container ipsec-sad-lifetime-hard {
description "IPsec SA lifetime hard";
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
container ipsec-sad-lifetime-soft {
description "IPsec SA lifetime soft";
uses lifetime;
leaf action {type lifetime-action; description "action lifetime";}
}
} }
grouping local-grouping { grouping local-grouping {
description "Configure the local peer in an IKE connection"; description "Configure the local peer in an IKE connection";
container local { container local {
description "Local container"; description "Local container";
choice my-identifier-type { choice my-identifier-type {
default ipv4; default ipv4;
case ipv4 { case ipv4 {
leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; } leaf ipv4 { type inet:ipv4-address; description "IPv4 dotted-decimal address"; }
} }
skipping to change at page 44, line 4 skipping to change at page 45, line 14
/*################# End Register grouping #################*/ /*################# End Register grouping #################*/
/*################## ipsec ##################*/ /*################## ipsec ##################*/
container ietf-ipsec { container ietf-ipsec {
description "Main IPsec container "; description "Main IPsec container ";
container ikev2 { container ikev2 {
if-feature case1; if-feature case1;
description "Configure the IKEv2"; description "Configure the IKEv2";
container ike-connection { container ike-connection {
description "IKE connections configuration"; description "IKE connections configuration";
list ike-conn-entries { list ike-conn-entries {
key "conn-name"; key "conn-name";
description "IKE peer connetion information"; description "IKE peer connetion information";
leaf conn-name { type string; mandatory true; description "Name of IKE connection";} leaf conn-name { type string; mandatory true; description "Name of IKE connection";}
leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";} leaf autostartup { type type-autostartup; mandatory true; description "if True: automatically start tunnel at startup; else we do lazy tunnel setup based on trigger from datapath";}
leaf nat-traversal { type boolean; default false; description "Enable/Disable NAT traversal"; } leaf nat-traversal { type boolean; default false; description "Enable/Disable NAT traversal"; }
leaf initial-contact {type boolean; default false; description "This IKE SA is the only currently active between the authenticated identities";}
container encap { container encap {
when "../nat-traversal = 'true'"; when "../nat-traversal = 'true'";
description "Encapsulation container"; description "Encapsulation container";
leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";} leaf espencap { type esp-encap; description "ESP in TCP, ESP in UDP or ESP in TLS";}
leaf sport {type inet:port-number; description "Encapsulation source port";} leaf sport {type inet:port-number; description "Encapsulation source port";}
leaf dport {type inet:port-number; description "Encapsulation destination port"; } leaf dport {type inet:port-number; description "Encapsulation destination port"; }
leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";} leaf oaddr {type inet:ip-address; description "Encapsulation Original Address ";}
} }
 End of changes. 17 change blocks. 
55 lines changed or deleted 100 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/