<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml"> zwsp   "&#8203;">
  <!ENTITY RFC5570 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5570.xml"> nbhy   "&#8209;">
  <!ENTITY RFC7296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-ipsecme-labeled-ipsec-12" number="9478" xml:lang="en" updates="" obsoletes=""
    category="std"
    docName="draft-ietf-ipsecme-labeled-ipsec-12"> tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.17.1 -->
  <front>
    <title abbrev="Labeled IPsec">Labeled IPsec Traffic Selector support Support for IKEv2 </title> the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
    <seriesInfo name="RFC" value="9478"/>
    <author initials='P.' initials="P." surname="Wouters" fullname='Paul Wouters'> fullname="Paul Wouters">
      <organization>Aiven</organization>
      <address>
        <email>paul.wouters@aiven.io</email>
      </address>
    </author>
    <author fullname="Sahana Prasad" initials="S." surname="Prasad">
      <organization>Red Hat</organization>
      <address>
        <email>sahana@redhat.com</email>
      </address>
    </author>

    <date/>

    <area>General</area>

    <workgroup>Network</workgroup>
    <date year="2023" month="September"/>
    <area>sec</area>
    <workgroup>ipsecme</workgroup>
    <keyword>IKEv2</keyword>
    <keyword>SPD</keyword>
    <keyword>SAD</keyword>
    <abstract>
      <t> This document defines a new Traffic Selector (TS) Type (TS Type) for
      the Internet Key Exchange Protocol version 2 (IKEv2) to add support for negotiating
      Mandatory Access Control (MAC) security labels as a traffic selector Traffic Selector
      of the Security Policy Database (SPD). Security Labels for IPsec
      are also known as "Labeled IPsec".  The new TS type is Type, TS_SECLABEL,
      which
      consists of a variable length opaque field specifying that specifies the
      security label.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t> In computer security, Mandatory Access Control (MAC) usually
        refers to systems in which all subjects and objects are assigned
        a security label. A security label is composed of a set of
        security attributes. The security labels along Along with a system
        authorization policy policy, the security labels determine access. Rules within the system
        authorization policy determine whether the access will be granted
      based on the security attributes of the subject and object.</t>

      <t> Historically, security labels used by Multilevel Systems Multi-Level Secure
        (MLS) systems are comprised of a sensitivity level (or classification)
        field and a compartment (or category) field, as defined in <xref
        target="FIPS188"/> and <xref target="RFC5570"/>. target="RFC5570" format="default"/>. As MAC systems
        evolved, other MAC models gained in popularity. For example,
        SELinux, a Flux Advanced Security Kernel (FLASK) implementation,
        has security labels represented as colon-separated ASCII strings
        composed of values for identity, role, and type. The security
        labels are often referred to as security contexts.</t>
      <t>Traffic Selector (TS) payloads specify the selection criteria
        for packets that will be forwarded over the newly set up IPsec
        Security Association (SA) as enforced by the Security Policy Database
        (SPD, see
        (SPD) <xref target="RFC4301"/>).</t>

        <t> This target="RFC4301" format="default"/>.</t>
      <t>This document specifies a new Traffic Selector Type
        TS_SECLABEL TS Type,
        TS_SECLABEL, for IKEv2 that can be used to negotiate security
        labels as additional selectors for the Security Policy Database
        (SPD) SPD
        to further restrict the type of traffic that is allowed to be sent
        and received over the IPsec SA.</t>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
        "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
        "OPTIONAL"
        "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
      <section title="Traffic numbered="true" toc="default">
        <name>Traffic Selector clarification"> Clarification</name>
        <t>The negotiation of Traffic Selectors is specified in Section 2.9 of <xref
        target="RFC7296"/> target="RFC7296" sectionFormat="of" section="2.9"/>, where it defines two TS
        Types (TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE). The Traffic
        Selector TS payload format is specified in Section 3.13 of <xref target="RFC7296"/>. target="RFC7296" sectionFormat="of" section="3.13"/>.
        However, the term Traffic Selector "Traffic Selector" is used to denote the traffic
        selector TS payloads and individual traffic selectors Traffic Selectors of that payload. Sometimes Sometimes,
        the exact meaning can only be learned from context or if the
        item is written in plural ("Traffic Selectors" or "TSs"). "TSes"). This
        section clarifies these terms as follows:</t>
        <t>A Traffic Selector (no (capitalized, no acronym) is one selector for traffic
        of a specific Traffic Selector Type (TS_TYPE). (TS Type).  For example example, a
        Traffic Selector of TS_TYPE TS Type TS_IPV4_ADDR_RANGE for UDP (protocol 17) traffic in
        the IP network 198.51.100.0/24 covering all ports, ports is denoted as
        (17, 0, 198.51.100.0-198.51.100.255)</t> 198.51.100.0-198.51.100.255).</t>
        <t>A Traffic Selector TS payload (TS) is a set of one or more Traffic
        Selectors of the same or different TS_TYPEs. TS Types. It typically contains
        one or more of the TS_TYPE TS Type of TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE.
        For example, the above Traffic Selector by itself in a TS payload is denoted as
        TS((17, 0, 198.51.100.0-198.51.100.255))</t>
      </section>
      <section title="Security numbered="true" toc="default">
        <name>Security Label Traffic Selector negotiation"> Negotiation</name>
        <t>The negotiation of Traffic Selectors is specified in Section 2.9 of <xref
        target="RFC7296"/> target="RFC7296" sectionFormat="of" section="2.9"/> and states that the TSi/TSr payloads MUST <bcp14>MUST</bcp14> contain at least one
        Traffic Selector type.
        TS Type. This document adds a new TS_TYPE TS Type of TS_SECLABEL that is
        valid only with at least one other type of Traffic Selector. TS Type. That is, it cannot
        be the only TS_TYPE TS Type present in a TSi or TSr payload. It MUST <bcp14>MUST</bcp14> be used along with
        an IP address selector type type, such as TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE.</t>
      </section>
    </section>
    <section title="TS_SECLABEL numbered="true" toc="default">
      <name>TS_SECLABEL Traffic Selector Type"> Type</name>
      <t>This document defines a new TS Type, TS_SECLABEL TS_SECLABEL, that contains a single new opaque Security Label.</t>
      <section title="TS_SECLABEL payload format"> numbered="true" toc="default">
        <name>TS_SECLABEL Payload Format</name>
        <figure align="center" anchor="tstype_seclabel" title="Labeled anchor="tstype_seclabel">
          <name>Labeled IPsec Traffic Selector"> Selector</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
|   TS Type     |    Reserved   |       Selector Length         |
+---------------+---------------+-------------------------------+
|                                                               |
~                         Security Label*                       ~
|                                                               |
+---------------------------------------------------------------+
]]></artwork>
        </figure>

    <t>*Note:
        <t>Note: All fields other than TS Type and Selector Length depend on
   the TS Type. The fields shown is are for TS Type TS_SECLABEL, which is the
   selector that this document defines.

   <list style="symbols">
   <t>TS
        </t>
<dl>
          <dt>TS Type (one octet) - Set octet):</dt><dd>Set to 10 for TS_SECLABEL,</t>

   <t>Selector TS_SECLABEL.</dd>
          <dt>Selector Length (2 (two octets, unsigned integer) - Specifies integer):</dt><dd>Specifies the
      length of this Traffic Selector substructure including the header.</t>

   <t>Security Label - An header.</dd>
          <dt>Security Label:</dt><dd>An opaque byte stream of at least one octet.</t>
   </list>
   </t> octet.</dd>
        </dl>
      </section>
      <section title="TS_SECLABEL properties"> numbered="true" toc="default">
        <name>TS_SECLABEL Properties</name>
        <t>The TS_SECLABEL Traffic Selector TS Type does not support narrowing or
      wildcards. It MUST <bcp14>MUST</bcp14> be used as an exact match value.</t>
        <t>The TS_SECLABEL Traffic Selector TS Type MUST NOT <bcp14>MUST NOT</bcp14> be the only TS_TYPE TS Type
      present in the TS payload payload, as TS_SECLABEL is complimentary to another
      type of Traffic Selector. There MUST <bcp14>MUST</bcp14> be an IP address Traffic Selector
      type
      Type in addition to the TS_SECLABEL Traffic Selector type TS Type in the Traffic
      Selector Payload. TS payload. If a TS payload is received with only TS_SECLABEL
      Traffic Selector types,
      TS Types, the exchange MUST <bcp14>MUST</bcp14> be aborted with an Error Notify
      message containing TS_UNACCEPTABLE.</t>
        <t>The Security Label contents are opaque to the IKE implementation.
   That is, the IKE implementation might not have any knowledge of regarding
   the meaning of this selector, selector other than recognizing it as a type and
   opaque value to pass to the SPD.</t>
        <t>A zero length zero-length Security Label MUST NOT <bcp14>MUST NOT</bcp14> be used. If a received
      TS payload contains a TS_TYPE TS Type of TS_SECLABEL with a zero length zero-length
      Security Label, that specific Traffic Selector MUST TS payload <bcp14>MUST</bcp14> be ignored. If no other Traffic Selector of TS_TYPE TS payload contains an acceptable TS_SECLABEL can be selected, TS Type, the exchange MUST <bcp14>MUST</bcp14> be aborted with a TS_UNACCEPTABLE Error Notify
      message. A zero length zero-length Security Label MUST NOT <bcp14>MUST NOT</bcp14> be interpreted as a
      wildcard security label.</t>

      <t>If
        <t> If multiple Security Labels are allowed for a given Traffic Selector's IP address range, protocol,
      start and end address/port match, port range, the initiator includes all of the these acceptable TS_SECLABEL's and the Security Labels. The responder MUST <bcp14>MUST</bcp14> select exactly one of them.</t> the Security Labels.</t>
        <t>A responder that selected a TS with TS_SECLABEL MUST <bcp14>MUST</bcp14> use the Security
      Label for all selector operations on the resulting TS. It MUST
      NOT <bcp14>MUST
      NOT</bcp14> select a TS_SECLABEL without using the specified Security Label,
      even if it deems the Security Label optional, as the initiator has
      indicated (and expects) that the Security Label will be set for all
      traffic matching the negotiated TS.</t>
      </section>
    </section>
    <section title="Traffic numbered="true" toc="default">
      <name>Traffic Selector negotiation"> Negotiation</name>
      <t>If the TSi Payload payload contains a traffic selector for TS_TYPE of Traffic Selector with TS Type
     TS_SECLABEL (along with another TS_TYPE), TS Type), the responder MUST <bcp14>MUST</bcp14> create
     each TS response for the other TS_TYPEs TS Types using its normal rules
     specified for each of those TS_TYPE, TS Types, such as narrowing them following
     the rules specified for that TS_TYPE, TS Type and then add adding exactly one for the
     TS_TYPE
     TS Type of TS_SECLABEL to the TS Payload(s). payload(s). If this is not possible,
     it MUST <bcp14>MUST</bcp14> return a TS_UNACCEPTABLE Error Notify payload.</t>
      <t>If the Security Label traffic selector TS Type is optional from a
      configuration point of view, an initiator will add the
      TS_SECLABEL to the TSi/TSr Payloads. payloads. If the responder replies with
      TSi/TSr Payloads payloads that include the TS_SECLABEL, then the Child SA
      MUST
      <bcp14>MUST</bcp14> be created including and include the negotiated Security Label. If the
      responder did not include a TS_SECLABEL in its response, then the
      initiator (which deemed the Security Label optional) will install
      the Child SA without including any Security Label. If the initiator
      required the TS_SECLABEL, it MUST NOT <bcp14>MUST NOT</bcp14> install the Child SA and it MUST <bcp14>MUST</bcp14>
      send a Delete notification for the Child SA so the responder can
      uninstall its Child SA.</t>
      <section title="Example numbered="true" toc="default">
        <name>Example TS negotiation"> Negotiation</name>
        <t>An initiator could send:</t> send the following:</t>
        <figure align="center" anchor="tstype_example_i" title="initiator anchor="tstype_example_i">
          <name>Initiator TS payloads example"> Payloads Example</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
TSi = ((17,24233,198.51.100.12-198.51.100.12),
       (0,0,198.51.100.0-198.51.100.255),
       (0,0,192.0.2.0-192.0.2.255),
       TS_SECLABEL1, TS_SECLABEL2)

TSr = ((17,53,203.0.113.1-203.0.113.1),
       (0,0,203.0.113.0-203.0.113.255),
       TS_SECLABEL1, TS_SECLABEL2)
]]></artwork>
        </figure>
        <t>The responder could answer with the following  example:</t> following:</t>
        <figure align="center" anchor="tstype_example_r" title="responder anchor="tstype_example_r">
          <name>Responder TS payloads example"> Payloads Example</name>
          <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
TSi = ((0,0,198.51.100.0-198.51.100.255),
       TS_SECLABEL1)

TSr = ((0,0,203.0.113.0-203.0.113.255),
       TS_SECLABEL1)
]]></artwork>
        </figure>
      </section>
      <section title="Considerations numbered="true" toc="default">
        <name>Considerations for using multiple TS_TYPEs Using Multiple TS Types in a TS"> TS</name>
        <t>It would be unlikely that the traffic for TSi and TSr would have
     a different Security Label, but this specification does allow allows this to
     be specified.
If the initiator does not support this, this and wants to prevent the responder from
picking different labels for the
     TSi / TSr TSi/TSr payloads, it should attempt a Child
SA negotiation and start with only the first Security Label first, and upon failure only. Upon failure, the
initiator should retry a new Child SA negotiation with only the second
Security Label.</t>
        <t>If different IP ranges can only use different specific Security
     Labels, then these should be negotiated in two different Child SA
     negotiations. If in In the example above, if the initiator only allows
     192.0.2.0/24 with TS_SECLABEL1, TS_SECLABEL1 and 198.51.100.0/24 with TS_SECLABEL2,
     than
     then it MUST NOT <bcp14>MUST NOT</bcp14> combine these two ranges and security labels
     into one Child SA negotiation.</t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>It is assumed that the Security Label can be matched by the IKE
       implementation to its own configured value, even if the IKE
       implementation itself cannot interpret the Security Label value.</t>
      <t>A packet that matches an SPD entry for all components components, except the
       Security Label Label, would be treated as "not matching". If no other SPD
       entries match, the (mis-labeled) (mislabeled) traffic might end up being transmitted
       in the clear. It is presumed that other Mandatory Access Control MAC methods
       are in place to prevent mis-labeled mislabeled traffic from reaching the IPsec
       subsystem,
       subsystem or that the IPsec subsystem itself would install a REJECT/DISCARD
       rule in the SPD to prevent unlabeled traffic otherwise matching
       a labeled security SPD rule from being transmitted without IPsec protection.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
        <t>This document defines one numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has added a new entry in the IKEv2 "IKEv2 Traffic Selector Types registry:</t>
        <t>[Note to RFC Editor (please remove before publication): This value has already been added
           via Early Allocation.]</t>

           <figure align="center" anchor="iana_requests">
               <artwork align="left"><![CDATA[
   Value   TS Type                      Reference
   -----   ---------------------------  -----------------
   10     TS_SECLABEL   [this document]
               ]]></artwork>
           </figure>
       </section>

    <section title="Implementation Status" anchor="impl_status">
     <t>
      [Note to RFC Editor: Please remove this section and the reference to Types" registry <xref target="RFC7942"/> before publication.]
     </t>
     <t>
      This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of
      this Internet-Draft, and is based on a proposal described in
      <xref target="RFC7942"/>. The description of implementations in this
      section is intended to assist the IETF in its decision processes
      in progressing drafts to RFCs. Please note that the listing of
      any individual implementation here does not imply endorsement
      by the IETF. Furthermore, no effort has been spent to verify the
      information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a catalog
      of available implementations or their features. Readers are advised
      to note that other implementations may exist.
     </t>
     <t>
      According to <xref target="RFC7942"/>, "this will allow reviewers
      and working groups to assign due consideration to documents that
      have the benefit of running code, which may serve as evidence of
      valuable experimentation and feedback that have made the implemented
      protocols more mature.  It is up to the individual working groups
      to use this information as they see fit".
     </t>
     <t>
      Authors are requested to add a note to the RFC Editor at the
      top of this section, advising the Editor to remove the entire
      section before publication, as well target="RFC7296"/> as the reference to <xref
      target="RFC7942"/>.
     </t>

     <section anchor="section.impl-status.libreswan" title="Libreswan">
      <t>
       <list style="hanging">
        <t hangText="Organization: ">The Libreswan Project</t>
        <t hangText="Name: "> https://lists.libreswan.org/mailman/listinfo/swan-dev/</t>
        <t hangText="Description: ">
           Implementation was introduced in 4.4, but 4.6 or newer should be used </t>
        <t hangText="Level of maturity: ">beta</t>
        <t hangText="Coverage: ">
            Implements the entire draft using SElinux based labels</t>
        <t hangText="Licensing: ">GPLv2</t>
        <t hangText="Implementation experience: ">No interop testing has been done yet. The code
           works including different labeled on-demand kernel ACQUIRES.</t>
        <t hangText="Contact: ">Libreswan Development: swan-dev@libreswan.org</t>
       </list>
      </t>
     </section> follows.</t>
<table anchor="iana_requests">
  <name>IKEv2 Traffic Selector Types Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>TS Type</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>10</td>
      <td>TS_SECLABEL</td>
      <td>RFC 9478</td>
    </tr>
  </tbody>
</table>
    </section>
  </middle>
  <back>

<displayreference target="I-D.jml-ipsec-ikev2-security-label" to="IPSEC-IKEV2-SECURITY-LABEL"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5570.xml"/>

<!-- [I-D.jml-ipsec-ikev2-security-label] IESG state Expired -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.jml-ipsec-ikev2-security-label.xml"/>

      </references>
    </references>
    <section title="Acknowledgements" anchor="acknowledgements"> anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>A large part of the introduction text was taken verbatim from <xref target="draft-jml-ipsec-ikev2-security-label"/>
      target="I-D.jml-ipsec-ikev2-security-label" format="default"/>, whose
      authors are J Latten, D. Quigley and J. Lu. Valery Smyslov <contact fullname="Joy Latten"/>, <contact fullname="David
      Quigley"/>, and <contact fullname="Jarrett Lu"/>. <contact
      fullname="Valery Smyslov"/> provided valuable input regarding IKEv2
      Traffic Selector semantics.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
     &RFC2119;
     &RFC7296;
     &RFC8174;
    </references>

    <references title="Informative References">
      &RFC4301;
      &RFC5570;
      &RFC7942;

     <reference anchor="FIPS188">
        <front>
          <title>National Institute of Standards and Technology, "Standard Security Label for Information Transfer"
          </title>
          <author initials="" surname="" fullname="National Institute of Standards and Technology">
            <organization>NIST</organization>
          </author>

          <date year="1994" month="September"/>
        </front>
        <seriesInfo name="Federal Information Processing Standard (FIPS)" value="Publication 188"/>
        <format type="HTML" target="https://csrc.nist.gov/publications/detail/fips/188/archive/1994-09-06"/>
      </reference>

   <reference anchor='draft-jml-ipsec-ikev2-security-label'>
      <front>
      <title>Security Label Extension to IKE</title>
      <author initials='J' surname='Latten' fullname='J. Latten'>
      <organization>IBM</organization>
      </author>
      <author initials='D' surname='Quigley' fullname='D. Quigley'>
      </author>
      <author initials='J' surname='Lu' fullname='J.Lu'>
      <organization>Oracle</organization>
      </author>
      <date month='January' day='28' year='2011' />
      <abstract><t>
       This document describes extensions to the Internet Key Exchange
       Protocol Version 2 RFC5996 to support Mandatory Access Control
       (MAC) security labels used on deployed systems.
       </t></abstract>
      </front>
   </reference>

    </references>
  </back>
</rfc>