One document matched: draft-lear-ietf-netmod-acl-dnsname-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-lear-ietf-netmod-acl-dnsname-00" category="std">

  <front>
    <title abbrev="DNS in ACLs">Using DNS Names in the IETF ACL Model</title>

    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@cisco.com</email>
      </address>
    </author>

    <date year="2016" month="January" day="19"/>

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>End points are commonly referenced by higher level functions through
the DNS. This is especially the case in cloud-based functions, which
might have hundreds of IP addresses for the same name.  This brief
memo extends the IETF-ACL model to allow access-control via domain
names.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">
<t>The IETF-ACL model <xref target="I-D.ietf-netmod-acl-model"/> specifies a schema
for access lists.  That model is intentionally kept constrained to the
small number of packet-passing functions that are considered
ubiquitous.  While that is a necessary step, there are a number of
circumstances in which it will not be sufficient.  In
a world where load balancing and shifting commonly takes place, it may
not be practical to maintain the complete list of IP addresses in all
instances.  Furthermore, even in more static environments,
occasionally the name to address mapping needs to change.  Lastly,
there are resources that may not be tied to packet processing at all
that may yet be well described by this augmentation.  Allowing
domain names in ACLs reduces the number of points within a network
that need to be reconfigured when such changes take place.</t>

<t>This memo specifies an extension to IETF-ACL model such that domain
names may be referenced by augmenting the “matches” element.
Different implementations may deploy differing methods to maintain the
mapping between IP address and domain name, if indeed any are needed.
However, the intent is that resources that are referred to using a
name should be authorized (or not) within an access list.</t>

<t>The structure of the change is as follows:</t>

<figure><artwork><![CDATA[
   augment
   /acl:access-lists/acl:acl/acl:access-list-entries
      /acl:ace/acl:matches/acl:ace-type/acl:ace-ip:
      +--rw source-dnsname?        inet:host
      +--rw destination-dnsname?   inet:host
]]></artwork></figure>

<t>The choice of this particular point in the access-list model is based
on the assumption that we are in some way referring to IP-related
resources, as that is what the DNS returns.  A domain name in our
context is defined in <xref target="RFC6991"/>.</t>

</section>
<section anchor="element-definitions" title="Element Definitions">

<t>The following elements are defined.</t>

<section anchor="source-dnsname" title="source-dnsname">
<t>The argument corresponds to a domain name of a source as specified by
inet:host. Depending on how the model is used, it may or may not be
resolved, as required by the implementation and circumstances.</t>

</section>
<section anchor="destination-dnsname" title="destination-dnsname">
<t>The argument corresponds to a domain name of a destination as
specified by inet:host. Depending on how the model is used, it may or
may not be resolved, as required by the implementation and
circumstances.</t>

</section>
</section>
<section anchor="the-ietf-acl-dnsname-model" title="The ietf-acl-dnsname Model">

<figure><artwork><![CDATA[
<CODE BEGINS>file "ietf-acl-dnsname.yang";

module ietf-acl-dnsname {
  yang-version 1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-acl-dnsname";
  prefix "ietf-acl-dnsname";
  
  
  import ietf-access-control-list {
    prefix "acl";
  }

  import ietf-inet-types
  {
    prefix "inet";
  }
  
  organization
    "Cisco Systems, Inc.";

  contact
    "Eliot Lear
     lear@cisco.com
    ";

  description
    "This YANG module defines a component that augments the
     IETF description of an access list to allow dns names
     as matching criteria.";

  revision "2016-01-14"  {
    description "Initial revision";
    reference "This document?";
  }

  augment "/acl:access-lists/acl:acl/" +
     "acl:access-list-entries/acl:ace/" +
     "acl:matches/acl:ace-type/acl:ace-ip" {
    description "adding domain names to matching";

    leaf source-dnsname {
      type inet:host;
      description "domain name to be matched against";
    }
    leaf destination-dnsname {
      type inet:host;
      description "domain name to be matched against";
    }
  }

}

<CODE ENDS>
]]></artwork></figure>

</section>
<section anchor="example" title="Example">

<t>The following example is taken from <xref target="I-D.ietf-netmod-acl-model"/> (the
optional and irrelevant components have been removed).  It allows
traffic from www.cloud.example.com.</t>

<figure><artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
  <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <access-lists
   xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list"
  xmlns:ietf-acl-dnsname="urn:ietf:params:xml:ns:yang:ietf-acl-dnsname">
       <acl>
        <acl-oper-data />
        <access-list-entries>
          <ace>
            <matches>
	      <source-dnsname>
	         www.cloud.example.com
	      </destination-dnsname>
            </matches>
            <actions>
              <permit />
            </actions>
            <rule-name>rule1<rule-name/>
          </ace>
        </access-list-entries>
        <acl-name>sample-dns-acl<acl-name/>
        <acl-type>ipv4-acl<acl-type/>
      </acl>
    </access-lists>
  </data>
]]></artwork></figure>

</section>
<section anchor="security-considerations" title="Security Considerations">
<t>If the mapping between a domain name and the underlying resource to
which it refers becomes stale, the access list will be incorrect.  It
is therefore important that implementations employ some means for
maintaining the mapping, if it is required.  In those circumstances,
when other systems are in play, those other systems would be required
to indicate what domains they are attempting to connect to.  Under the
current circumstances, this is readily observable.  However, in future
such information sharing may raise privacy concerns, and the name and
mapping may not be available to the system employing the ACL model.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>The IANA is not requested to make any changes.  The RFC Editor is
requested to remove this section prior to publication.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The author wishes to acknowledge Kiran Koushik and Einar
Nilsen-Nygaard for their review and contributions to this work.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-netmod-acl-model'>
<front>
<title>Network Access Control List (ACL) YANG Data Model</title>

<author initials='D' surname='Bogdanovic' fullname='Dean Bogdanovic'>
    <organization />
</author>

<author initials='K' surname='Koushik' fullname='Kiran Koushik'>
    <organization />
</author>

<author initials='L' surname='Huang' fullname='Lisa Huang'>
    <organization />
</author>

<author initials='D' surname='Blair' fullname='Dana Blair'>
    <organization />
</author>

<date month='December' day='9' year='2015' />

<abstract><t>This document describes a data model of Access Control List (ACL) basic building blocks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-netmod-acl-model-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-06.txt' />
</reference>



<reference  anchor='RFC6991' target='http://www.rfc-editor.org/info/rfc6991'>
<front>
<title>Common YANG Data Types</title>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='editor'><organization /></author>
<date year='2013' month='July' />
<abstract><t>This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t></abstract>
</front>
<seriesInfo name='RFC' value='6991'/>
<seriesInfo name='DOI' value='10.17487/RFC6991'/>
</reference>




    </references>




  </back>
</rfc>