<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC4301 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4302 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC5840 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5840.xml">
<!ENTITY RFC7296 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC8247 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml">
<!ENTITY RFC8221 SYSTEM
  "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml">
]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>

<rfc
  category="info"
  docName="draft-nir-i2nsf-ipsec-dc-prof-00"
  ipr="trust200902"
  consensus="no"
  submissionType="IETF"
  xml:lang="en"
>

<front>

    <title abbrev='IPsec DC Profile'>
        A Data Center Profile for Software Defined Networking (SDN)-based IPsec 
    </title>
    <author fullname='Yoav Nir' initials='Y.' surname='Nir'>
        <organization>DellEMC</organization>
        <address>
            <postal>
                <street>9 Andrei Sakharov St</street>
                <city>Haifa</city>
                <code>3190500</code>
                <country>Israel</country>
            </postal>
            <email>ynir.ietf@gmail.com</email>
        </address>
    </author>
    
    <date/>
    
    <area>Security</area>
    <workgroup>I2NSF</workgroup>
    
    <keyword>IPsec</keyword>
    <keyword>SDN</keyword>
    <keyword>Profile</keyword>
    <keyword>datacenter</keyword>
    
    <abstract>
        <t> This document presents two profiles for configuring IPsec within a data center using an SDN
            controller and the YANG model described in the sdn-ipsec draft.</t>
        <t> Two profiles are described to allow both the IKE and IKE-less cases because some data centers
            may be required to use a standardized method of key exchange rather than SDN.</t>
    </abstract>
</front>

<middle>

    <section anchor='intro' title="Introduction">
        <t> <xref target='sdn-ipsec'/> describes a YANG model that allows a software defined networking (SDN) 
            controller to configure the use of IP security (IPsec - <xref target='RFC4301'/>) and optionally 
            the Internet Key Exchange protocol (IKEv2 - <xref target='RFC7296'/>) to secure IP traffic between 
            the hosts that it controls.</t>
        <t> The SDN-IPsec document allows for configuration of most of the options available in IPsec. However,
            not every one of those options are appropriate for all use cases.</t>
        <t> The use case that is covered here is the need to encrypt traffic between hosts within a data
            center. As explained in <xref target='env'/>, data centers cannot be considered a secure 
            environment where internal communications are safe behind the firewall. One way to protect the
            internal traffic is to configure TLS pair-wise between the hosts, but <xref target='sdn-ipsec'/> 
            provides a more convenient, automated solution.</t>
        <t> This document presents two profiles that are appropriate for encrypting traffic among the hosts in 
            a data center, one with and one without the use of IKE.</t>

        <section anchor="mustshouldmay" title="Terminology">
            <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
                "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
                BCP 14 <xref target='RFC2119'/> <xref target='RFC8174'/> when, and only when, they appear in 
                all capitals, as shown here.</t>
            <t> "Security Controller" or "SC" is an SDN controller used to configure security policy. For the 
                purposes of this document, we limit the use of this term to an SDN controller that distributes 
                IPsec policy.</t>
            <t> "Data center hosts" is the term we use for any machine in the data center that communicates 
                using Internet Protocol (IP) with other machines, both within and outside the data center.</t>
            <t> "Network Security Functions" or NSF is the term used for a host in the data plane that 
                implements a security function. For the purposes of this document we will call a host that has
                an IPsec stack and the software necessary to be configured by an SC an "IPsec NSF".</t>
            <t> "Control Domain" will be used here to mean the set of all IPsec NSFs controlled by a particular
                security controller. The controller can set up security associations within the control domain, 
                but any associations from within the domain to hosts or gateways outside of the domain have to 
                be configured on the remote host as well. The controller can, however, configure the local side
                of things, as mentioned in <xref target="others"/>.</t> 
        </section>
    </section>
    
    <section anchor='env' title="Assumptions About The Evnironment">
        <t> A modern data center usually has many systems from several different vendors containing data with
            varying levels of sensitivity. In the past people often assumed that the data center was protected
            from traffic interception by physical security. It was assumed that traffic within the data center
            or within the corporate network could safely be sent in the clear. This perception no longer holds 
            if it ever did. (TODO: citation needed).</t>
        <t> The servers in today's data center are connected both to corporate systems outside the data center
            as well as to public clouds and the Internet. Even if physical security is maintained, the threat 
            of a compromised server intercepting internal traffic is very real. In practice, even the physical
            security cannot be consistently maintained, as technicians from multiple vendors are often allowed
            physical access to the data center and supervision of those technicians is often lax.</t>
        <t> Additionally, certain industries or types of data are regulated to require encryption of all data
            in transit. Medical information, personal information, and financial information are examples of 
            data that often requires protection both at rest and in transit. For these reasons it is often
            necessary to encrypt traffic within the data center, between the data center and corporate 
            networks, and between the data center and public clouds.</t>
        <t> IPsec is a good option for encrypting traffic between servers. It provides the required 
            confidentiality and message authentication, and it is included in every common operating system as 
            well as third party vendor products It can be imposed by server administrators without any changes 
            to or configuration of the applications running on the servers.</t>
        <t> The problem with using IPsec has been that its configuration is difficult. The data structures 
            described in <xref target='RFC4301'/> require that data center hosts should all be configured
            with Peer Authentication Database (PAD) and Security Policy Database (SPD) entries for each 
            peer host, plus either pair-wise shared secrets or public-key based credentials. There has never
            been a scalable way to perform this mass configuration until <xref target='sdn-ipsec'/>, which 
            allows an SDN controller (renamed to Security Controller) to configure all of the necessary
            information so that any two data center hosts can communicate using IPsec.</t>
        <t> The following assumptions are made:
            <list style="symbols">
                <t> That an SC as described in <xref target='sdn-ipsec'/> is present in the data center.</t>
                <t> That the data center hosts are also IPsec NSFs, that they implement the NSF role of an 
                    <xref target="sdn-ipsec"/> implementation, and that they can all be configured by the 
                    above-mentioned SC.</t>
                <t> That the IPsec NSFs are relatively new, so that they include implementations of current 
                    cryptographic algorithms.</t>
                <t> That the connection between the SC and the IPsec NSFs is secure. Specifically, that it is 
                    safe to transmit keys and secret credentials over that connection.</t>
                <t> That the SC can produce enough good random bits to periodically produce pair-wise keys for 
                    as many IPsec NSFs as it can control.</t>
                <t> That both the IKE and IKE-less cases from <xref target="sdn-ipsec"/> are technically
                    viable. In other words, the software on the IPsec NSFs can accommodate both.</t>
            </list></t>
        <t> If the last point does not hold, and the NSFs can only accommodate IPsec (but not IKE), then only
            the IKE-less option is viable. At this point in time, I am not aware of any such NSFs.</t>
        <section anchor="blocking" title="Block and Bypass Traffic">
            <t> Not all nodes in a data center are supposed to communicate with one another at all, and some
                traffic does not need to be encrypted. In other words, a mesh is not the most appropriate 
                topology for IPsec on the network. The controller can enforce this lack of communication with 
                policy that blocks all communications that are not needed with the action "block" and allow
                some unprotected traffic with the action "bypass".</t>
            <t> This means that with N IPsec NSFs, there will be far less than N^2 security associations. A 
                mesh is still a valid configuration, but it's not usually the most appropriate. Using "block" 
                actions to prevent unwanted communications is as much a part of enforcing a security policy in 
                the data center as encrypting legitimate traffic.</t>
            <t> The particulars of what traffic should be allowed in the clear, what should be protected, and
                what should be blocked are, of course, unique to each organization and this document cannot 
                make any rules about that. Most often, the last or "cleanup" rule in the policy should be a 
                universal "block" rule.</t>
        </section>
    </section>
    
    <section anchor="profile" title="Profiles For Data Center Hosts">
        <t> This section presents two profiles for using IPsec in the data center: one that includes IKE, 
            and one that does not.  The choice between these two is entirely up to the regulatory regime.
            The IKE-less profile is simpler and requires less components.  It is preferable unless the
            regulatory regime demands the use of an Authenticated Key Exchange (AKE) method such as IKEv2.</t>
        <section anchor="prof-ikefull" title="IKE Profile">
            <t> With an IKE profile, all pairs of hosts that are supposed to communicate securely with one 
                another SHALL be issued shared secrets. The shared secrets MUST be generated independently of 
                one another by the controller using a true random number generator (TRNG) or a secure 
                pseudo-random number generator (PRNG) for each pair of hosts.</t>
            <t> Only IKEv2 will be used.</t>
            <t> The identities configured for the PAD can either be meaningful names from the configuration of
                the controller, or they can be generated sequentially by the controller. In either case the 
                ID type SHALL be Key ID (See section 4.4.3.1 of <xref target="RFC4301"/>)</t>
            <t> The algorithms used within IKEv2 SHALL be selected from among those marked MUST, SHOULD, and
                SHOULD+ in <xref target="RFC8247"/> without the "(IoT)" label, or a newer RFC that will
                obsolete RFC 8247 (TODO: why is this not a BCP?)</t>
            <t> The lifetime for an IKE SA SHALL be 24 hours. The lifetime for an ESP SA SHALL be 8 hours.</t>
            <t> For both IKE and IPsec, the controller MUST specify exactly one set of algorithms for each
                pair of nodes. The controller SHOULD specify one set of algorithms for all the associations
                in the system, unless one of the following applies:<list style="numbers">
                <t> The preferred algorithm is not supported by all nodes, so those that do not support it have
                    to use another algorithm.</t>
                <t> Different algorithms have different performance on different NSFs. For example, AES-GCM is
                    faster than ChaCha20-Poly1305 on Intel platforms, while ChaCha20-Poly1305 is faster on ARM
                    platforms. It can be advantageous to use one or the other depending on the types of systems
                    communicating.</t></list></t>
            <t> The rest of the properties are similar to those in the IKE-less profile (<xref 
                target="prof-ikeless"/>)</t>
        </section>
        <section anchor="prof-ikeless" title="IKE-Less Profile">
            <t> All security associations MUST have selectors (see section 4.4.1.1 of <xref target="RFC4301"/>)
                that have a single local address and a single remote address with no value for protocols or
                ports. TBD: exception for multi-homed hosts?</t>
            <t> All security associations are provided proactively. The controller does not wait for a request
                from the NSF for an SA.</t>
            <t> The controller SHOULD refresh the SAs every hour, and MAY do this more often if the volume of
                traffic exceeds the limits of the algorithms used.</t>
        </section>
        <section anchor="prof-both" title="Propertied Common to Both Profile">
            <t> All SPD entries MUST have selectors that have a single local address and a single remote 
                address with no value for protocols or ports. This, in the IKE case will lead to SAs as 
                described in the first paragraph of <xref target="prof-ikeless"/>, so this requirement does not
                need to be repeated. TBD: exception for multi-homed hosts?</t>
            <t> All algorithms used in IPsec MUST be those marked MUST, SHOULD, and SHOULD+ in <xref 
                target="RFC8221"/>, or a newer RFC that will obsolete RFC 8221 (TODO: why is this not a BCP?)</t>
            <t> All SAD entries MUST be regular ESP <xref target="RFC4303"/>. AH <xref target="RFC4302"/> and 
                WESP <xref target="RFC5840"/> are not supported in this profile.</t>
            <t> All SAs SHOULD use tunnel-mode. They MAY use transport mode only if all NSFs support this.</t>
        </section>
        <section anchor="others" title="Communications Outside the Domain">
            <t> Associations between NSFs in the domain and NSFs that are not in the domain are outside the 
                scope of this document. The security controller may configure the NSFs in the domain with the 
                IKE case, but success of the communications depends on the other NSF being configured in a 
                compatible way.</t>
            <t> Because of this dependency, the advice in this document do not apply: It is fine to support 
                multiple algorithms, it is fine to support subnets and/or specific protocols and ports, and 
                it is also OK to use other ID types and certificates. That configuration can co-exist in the 
                NSFs with the configuration specified in this profile, but is out of scope here.</t>
        </section>
    </section>

    <section anchor="ratio" title="Rationale for the Properties in the Profile">
        <t> The sub-sections below explain the rationale for the content of <xref target="profile"/>.</t>
        <section anchor="why_ikeless" title="Why IKE-less is preferrable">
            <t> IKEv2 <xref target="RFC7296"/> is a protocol for authenticating peers and generating traffic
                encryption keys. It allows peers that have a good random number generator to be configured 
                either once or rarely, and still be able to communicate securely over the Internet.</t>
            <t> IKEv2 thus addresses two issues that are not at all problematic for IPsec NSFs that are
                configured by an SC. The SC can configure the NSF as often as necessary, and already has the 
                identities established through its own secure channel with those NSFs.</t>
            <t> For this reason, setting up the traffic keys directly by the SC where it exists and controls 
                all the relevant hosts is not an inferior solution. It should be preferred for its simplicity, 
                its lower latency, and because it avoids relying on the random number generator within the NSF.</t>
        </section>
        <section anchor="whynotpki" title="Shared Secrets vs PKI">
            <t> We chose to use shared secrets in <xref target="prof-ikefull"/> because they are simpler than
                PKI and require less infrastructure. PKI has an advantage when configuring the hosts pair-wise
                is difficult. However, using a security controller means that changing the configuration or 
                generating pair-wise secrets for even a large number of hosts is attainable. With this change
                of assumption, it no longer makes sense to use PKI with its expiration times, revocation 
                checks and hierarchical signature verification.</t>
        </section>
        <section anchor="whyonealg" title="Why just one algorithm in IKE">
            <t> IKEv2 allows peers to each support multiple algorithms, and the protocols selects one that is
                supported by both. This is a good feature for interoperability between peers that are 
                configured separately. When configuring the peers with SDN IPsec, both peers are configured by
                the same controller, so there is no reason for them to offer any algorithm except the one 
                preferred by the controller.</t>
        </section>
        <section anchor="mustminus" title="Why not MUST-">
            <t> In both <xref target="prof-ikefull"/> and <xref target="prof-both"/> we required the use of 
                algorithms marked as MUST, SHOULD, or SHOULD+.  We excluded those marked as MUST-, even though
                these seem to be at a higher level of preference than those marked SHOULD or SHOULD+.</t>
            <t> The reason for this is that despite what <xref target="RFC8221"/> says, algorithms tend to be
                deprecated quickly and may fall from MUST- to MAY or even MUST NOT.  The only algorithm marked
                as MUST- in those drafts in HMAC-SHA1, and it would have been at the MAY or lower level had it
                not been for the fact that it is the most widely deployed algorithm, and disabling it may lead 
                to interoperability problems.</t>
            <t> In a new deployment such as this, there is no reason to keep using such an outdated algorithm
                that is very likely on its way out.</t>
        </section>
        <section anchor="proactive" title="Proactive vs Reactive Model">
            <t> The profile in <xref target="prof-ikeless"/> is proactive. SAs are installed in the NSFs along
                with the policy, and are maintained as long as the policy remains. We never wait for the NSF to
                request an SA. There are two reasons for this: <list style="numbers">
                <t> Creating the SAs proactively eliminates any latency in processing a packet at the NSF.</t>
                <t> The cost of an unused SA is very low in the NSF -  usually on the order of a few hundreds
                    of bytes. The cost at the controller of managing these SAs is also low. If SAs are 
                    generated every 8 hours and there are 1000 IPsec NSFs in a mesh, that's still just a 
                    million tunnels and only 35 needing to be rekeyed per second.</t></list></t>
        </section>
    </section>

    <section anchor='IANA' title="IANA Considerations">
        <t> There are no requests for IANA in this document.</t>
    </section>
    <section anchor='Security' title="Security Considerations">
        <t> The entire document is about security. The considerations in <xref target="sdn-ipsec"/> apply.
            Additionally, <xref target="ratio"/> contains explanation of the thinking behind the security
            decisions in this document.</t>
        <t> The environment where this profile is expected to be used is described in the Introduction 
            (<xref target="intro"/>), and is an internal network of a data center rather than the open 
            Internet. Despite this, no assumptions are made about the network between IPsec NSFs being in any
            way safer than the open Internet: the connection between controller and NSF is required to be 
            secure, and traffic keys are set up in a secure way: either over the controller-NSF secure 
            connection, or using IKEv2.</t>
        <t> The communication channel between the security controller and the NSF is required to be secure 
            because it carries traffic keys, credentials, or both.</t>
        <t> A risk that is not addressed in this document is that of an attacker blocking or delaying messages
            from the controller to the NSFs so as to prevent the timely setup of security associations. Such an 
            attack can lead to denial of service if the IPsec NSFs are configured to fail closed, or to sending
            traffic in the clear if they are configured to fail open, which may be valid if it is expected that
            only some of the traffic in the data center is to be encrypted. This risk has to be mitigated by 
            normal data center operations which should ensure that nodes in the data center, in this case the 
            controller and the NSF, are not blocked.</t>
    </section>
    <section anchor='TODO' title="ToDo">
        <t> Need to add a reference to https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/draft</t>
    </section>

</middle>

<back>

    <references title="Normative References">
        &RFC2119;
        &RFC8174;
        &RFC8247;
        &RFC8221;
        <reference anchor='sdn-ipsec'>
            <front>
                <title>Software-Defined Networking (SDN)-based IPsec Flow Protection</title>
                <author initials='R' surname='Lopez' fullname='Rafael Lopez'></author>
                <author initials='G' surname='Lopez-Millan' fullname='Gabriel Lopez-Millan'></author>
                <author initials='F' surname='Pereniguez-Garcia' fullname='Fernando Pereniguez-Garcia'></author>
                <date month='March' day='11' year='2019' />
            </front>
            <seriesInfo name='Internet-Draft' value='draft-ietf-i2nsf-sdn-ipsec-flow-protection-04' />
            <format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt' />
        </reference>
    </references>

    <references title="Informative References">
        &RFC4301;
        &RFC4302;
        &RFC5840;
        &RFC4303;
        &RFC7296;
    </references>

</back>
</rfc>