<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->


<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4595 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4595.xml">
<!ENTITY RFC7296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"
    updates="7296"
    obsoletes=""
    category="std"
    docName="draft-sprasad-ipsecme-labeled-ipsec-00">

  <!-- category values: std, bcp, info, exp, and historic -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Labeled IPsec">Labeled IPsec Traffic Selector support for IKEv2</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

<author fullname="Sahana Prasad" initials="S." surname="Prasad">
    <organization>Technical University of Munich</organization>
    
    <address>
        <email>sahana.prasad07@gmail.com</email>
    </address>
</author>
<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
     <organization>Red Hat</organization>
     <address>
      <email>pwouters@redhat.com</email>
     </address>
    </author>
    
    
    <date/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
     in the current day and month for you. If the year is not the current one, it is 
     necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
     purpose of calculating the expiry date).  With drafts it is normally sufficient to 
     specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
     If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>IKEv2</keyword>
    <keyword>IPsec</keyword>
    <keyword>SPD</keyword>
     <keyword>SAD</keyword>
     <keyword>TS</keyword>
    
   

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
        <t>Some IPsec implementations support Security Labels otherwise known as Security Contexts, to be configured as a selector within the Security Policy Database (SPD) for IPsec SAs. This document adds support to IKEv2 to negotiate these Security Labels or Contexts using a new Traffic Selector (TS) Type TS_SECLABEL. The approach is named "Labeled IPsec". It assumes that the SPD processing of RFC 4303 is already extended to support Security Labels. This document only adds the ability for IKE to negotiate the Security Labels used with the SPD.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

        <t> A Security Context or Security Label is a mechanism used to classify resources. It allows the enforcement of rules on how or by whom these resources are accessable. This document introduces a mechanism to negotiate these values using IKE. This negotiation is done via a new Traffic Selector (TS) Type in the TSi/TSr Payloads of the IKE_AUTH Exchange. </t>
        
        <t> Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. Section 2.9 in the Internet Key Exchange protocol version 2 <xref target="RFC7296"/> illustrates the Traffic selector negotiation procedure. </t>
        
        <t> Two or more TS payloads appear in each of the messages in the exchange that creates a Child SA pair.  Each TS payload contains one or more Traffic Selectors. The Traffic Selector types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE consists of an address range, a port range, and an IP protocol ID. <xref target="RFC4595"/> defines Traffic Selector type TS_FC_ADDR_RANGE to denote a list of Fibre Channel (FC) addresses and protocol ranges. This document extends the above set by adding a new TS Type that allows endpoints to agree on assigning a Security Label or Context to the IPsec SA. </t>
       
        <t> Negotiating and applying the Security Label or Context in the new TS Type will act as an additional selector criterium that has to match along with any other existing Traffic Selectors.
        </t>
    

      <section title="Requirements Language">
        <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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
      
    </section>
    


<section title="Labeled IPsec Traffic Selector" anchor="internal_domain">
     <t> Labeled IPsec Traffic Selectors allow endpoints to negotiate the Security Label using the
         Selector Type TS_SECLABEL. In addition to the regular prcessing of Traffic Selectors as
         described in Section 3.13.1 of <xref target="RFC7296"/>, the context or label of an IP
         packet now also has to match the Security Label Traffic Selector.
     </t>
    <figure align="center">
        <artwork align="left"><![CDATA[
0                   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><list style="symbols">
        <t>TS TYPE (one octet) - Specifies the type of Traffic Selector.</t>
        <t>Selector Length (2 octets, network byte order) - Specifies the length of Security Label including the header.</t>
        <t>Security Label - This field contains the opaque payload. </t>
    </list></t>
    
    <t>The following table lists the assigned value for the Labeled IPsec
        Traffic Selector Type field:</t>
    <figure align="center" >
        <artwork align="left"><![CDATA[
            
            TS Type       Value
            -------       -----
            TS_SECLABEL   [TBD]
            
        ]]></artwork>
    </figure>
    
    <t>To indicate support and a requirement for agreeing on a specific security context, the initiator MUST include the security context or label via TS_SECLABEL in the TSi (Traffic Selector-initiator) and TSr (Traffic Selector-responder) Payloads. On reception of TS_SECLABEL, the responder MUST find a matching Security Policy Database (SPD) entry that contains a Security Label and match the proposed label. Assuming that this proposal was acceptable to the responder, it would send the same or narrowed TS payloads in the IKE_AUTH reply. If the Security Label was not found in the SPD by the responder, it MUST respond with a TS_UNACCEPTABLE Notify message.</t>
    <t> As per section 2.9.2 in <xref target="RFC7296"/>, TS sets MUST BE kept identical during rekey. If a Security Label needs to change, the IPsec SA must be torn down and a new one must be negotiated with the updated TS_SECLABEL values.</t>
    
    <section title="Narrowing of Labeled IPsec Traffic Selector">
        <t> The IKE daemon might or might not be able to interpret the Security Label beyond an exact match. It might be possible for the IKE daemon to apply narrowing to the Security Labels. For example, a Security Label "Top Secret" could mean that this IPsec SA may also transport traffic with label "Secret". An initiator requesting "Top Secret" might be willing to be narrowed down to a "Secret" security context. Or a security context of "*" might mean "any security context". If the daemon does not interpret the Security Label, then it can only support an exact match of the raw data of the TS. </t>

        <t> The rules of responder narrowing as explained in section 2.9 in <xref target="RFC7296"/> are applicable to TS_SECLABEL. </t>
        <t> The TS_SECLABEL Traffic Selector Type if present MUST be mutually agreed upon. If one side includes a TS_SECLABEL and the other sides does not, the IPsec SA negotiation MUST fail with TS_UNAVAILABLE. If a responder insists on a TS_SECLABEL security context and receives a TSi/TSr set that does not contain a TS_SECLABEL Traffic Selector, it MUST fail the negotiation with TS_UNAVAILABLE. </t>
        <t> DISCUSS: Should a TS_SECLABEL of length 0 be allowed? If so, should it mean "any label" ?</t>
    </section>
    
 </section>

<section anchor="Security" title="Security Considerations">
    <t> While matching the Security Label on the endpoints, an assumption that the Security label will contain only ASCII text MUST NOT be made. If the Security Label is handed off to a helper routine for interpretation, it MUST be assumed that the content can be malicious. While Security Labels might look like text, there is no guarantee this text is null terminated. </t>
    <t> Any errors in handling the SPD entry, such as failing to add the SPD entry with the negotiated Security Label, MUST be abled as any other failure of SPD processing as defined in <xref target="RFC4303"/>.</t>
</section>

    <section anchor="IANA" title="IANA Considerations">
        <t>This document defines one new Traffic Selector Type in the IKEv2 Traffic Selector Types Registry namespace.</t>
        <figure align="center" anchor="iana_requests">
            <artwork align="left"><![CDATA[
                
          TS Type       Value
          -------       -----
          TS_SECLABEL   [TBD]

            ]]></artwork>
        </figure>
    </section>


  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search. These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
     &RFC2119;
     &RFC7296;
     &RFC4595;
    </references>
    <references title="Informative References">
     &RFC4303;
    </references>

  </back>
</rfc>
