One document matched: draft-baker-ipv6-isis-dst-flowlabel-routing-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section, 
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
                                 string such as <29> printed in the blank line at the 
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.  
         Note the ToC may be omitted for very short documents, but idnits insists on a ToC 
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references. 
         Some like symbolic tags in the references (and citations) and others prefer 
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
         main section on a new page but does not omit the blank lines between list items. 
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-isis-dst-flowlabel-routing-01"
     ipr="trust200902">
  <front>
    <title abbrev="IS-IS Source/Destination Routing">Using IS-IS with
    Token-based Access Control</title>

    <author fullname="Fred Baker" initials="F.J." surname="Baker">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street/>

          <city>Santa Barbara</city>

          <code>93117</code>

          <region>California</region>

          <country>USA</country>
        </postal>

        <email>fred@cisco.com</email>
      </address>
    </author>

    <date year="2013"/>

    <area>Internet Engineering Task Force</area>

    <workgroup/>

    <abstract>
      <t>This note describes the changes necessary for IS-IS to route IPv6
      traffic specified prefix if and only if the packet contains an
      authorization token.</t>
    </abstract>

    <!--		
		<note title="Foreword">
		</note>
		-->

    <!--
      <?rfc needLines="10" ?>
      <texttable anchor="table_example" title="A Very Simple Table">
      <preamble>Tables use ttcol to define column headers and widths.
      Every cell then has a "c" element for its content.</preamble>
          <ttcol align="center">ttcol #1</ttcol>
                                    <ttcol align="center">ttcol #2</ttcol>
                      <c>c #1</c>		<c>c #2</c>
                      <c>c #3</c>		<c>c #4</c>
                      <c>c #5</c>		<c>c #6</c>
      <postamble>which is a very simple example.</postamble>
      </texttable>
    -->
  </front>

  <middle>
    <!--		
      <t>There are multiple list styles: "symbols", "letters", "numbers", 
"hanging", "format", etc.</t>
      <t>
	<list style="symbols">
	    <t>First bullet</t>
	    <t>Second bullet</t>
	</list>
     </t>
-->

    <!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
	ASCII artwork goes here... 
]]>
</artwork>
</figure>
-->

    <section title="Introduction">
      <t>This specification builds on <xref target="RFC5308">IS-IS for
      IPv6</xref> and its extensible TLV. This note defines the sub-TLV for an
      <xref target="RFC2460">IPv6</xref> Flow Label, to define routes from to
      a destination prefix qualified by an authorization token.</t>

      <t>The approach may be combined with other qualifying attributes, such
      as routing "to that destination AND from a specified source". The
      obvious application is data center inter-tenant routing using a form of
      token-based access control. If the sender doesn't know the value to
      insert in the flow label or hop-by-hop option (the receiver's tenant
      ID), he in effect has no route to that destination.</t>

      <?rfc needLines="5" ?>

      <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"/>.</t>
      </section>
    </section>

    <section anchor="extensions" title="Theory of Routing">
      <t>Both IS-IS and OSPF perform their calculations by building a lattice
      of routers and links from the router performing the calculation to each
      router, and then use routes (sequences in the lattice) to get to
      destinations that those routes advertise connectivity to. Following the
      SPF algorithm, calculation starts by selecting a starting point
      (typically the router doing the calculation), and successively adding
      {link, router} pairs until one has calculated a route to every router in
      the network. As each router is added, including the original router,
      destinations that it is directly connected to are turned into routes in
      the route table: "to get to 2001:db8::/32, route traffic to {interface,
      list of next hop routers}". For immediate neighbors to the originating
      router, of course, there is no next hop router; traffic is handled
      locally.</t>

      <t>In this context, the route is qualified by an authorization token,
      carried in the flow label or a hop-by-hop option; It is installed into
      the FIB with the destination prefix, and the FIB applies the route if
      and only if the token in the packet matches the token in the route. Of
      course, there may be multiple LSPs in the RIB with the same destination
      and differing authorization tokens; these may also have the same or
      differing next hop lists. The intended forwarding action is to forward
      matching traffic to one of the next hop routers associated with this
      destination and authorization tokens, or to discard non-matching traffic
      as "destination unreachable".</t>

      <t>LSAs that lack an authorization tokens sub-TLV match any token that
      may be present, by definition.</t>

      <?rfc needLines="5" ?>

      <section title="Dealing with ambiguity">
        <t>In any routing protocol, there is the possibility of ambiguity. For
        example, one router might advertise a fairly general prefix - a
        default route, a discard prefix (which consumes all traffic that is
        not directed to an instantiated subnet), or simply an aggregated
        prefix while another router advertises a more specific one. In
        source/destination routing, potentially ambiguous cases include cases
        in which the link state database contains two routes A->B' and
        A'->B, in which A' is a more specific prefix within the prefix A
        and B' is a more specific prefix within the prefix B. Traditionally,
        we have dealt with ambiguous destination routes using a "longest match
        first" rule. If the same datagram matches more than one destination
        prefix advertised within an area, we follow the route with the longest
        matching prefix.</t>

        <t>In this case, we follow a similar but slightly different rule; the
        FIB lookup MUST yield the route with the longest matching destination
        prefix that also matches the authorization token. A FIB route with no
        such token matches any authorization token. </t>
      </section>

      <?rfc needLines="5" ?>

      <section title="Interactions with other constraints">
        <t>In the event that there are other constraints on routing, such as
        proposed in <xref target="I-D.baker-ipv6-isis-dst-src-routing"/>, the
        effect is a logical AND. The FIB lookup must yield the route with the
        longest matching destination prefix that also matches each of the
        constraints.</t>
      </section>
    </section>

    <section anchor="IS-IS-extensions-ipv6"
             title="Extensions necessary for IPv6 Authenticated Routing in IS-IS">
      <t>Section 2 of <xref target="RFC5308"/> defines the "IPv6 Reachability
      TLV", and carries in it destination prefix advertisements. It has the
      capability of extension, using sub-TLVs.</t>

      <t>In this model, the flow label is used to prove that the datagram's
      sender has specific knowledge of its intended receiver. No proof is
      requested; this is left for higher layer exchanges such as IPSec or TLS.
      However, if the information is distributed privately, such as through
      DHCP/DHCPv6, the network can presume that a system that marks traffic
      with the right flow label has a good chance of being authorized to
      communicate with its peer.</t>

      <t>The key consideration, in this context, is that the flow label is a
      20 bit number. As such, an advertised route requiring a given flow label
      value is calling for an exact match of all 20 bits of the label
      value.</t>

      <section anchor="IS-IS-label" title="Authorization Token sub-TLV">
        <?rfc needLines="10"?>

        <figure title="Source Prefix Sub-TLV">
          <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Length     |  MBZ  | 20 bit Flow Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |
+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t><list style="hanging">
            <t hangText="Source Prefix Type:">assigned by IANA</t>

            <t hangText="TLV Length:">Length of the sub-TLV in octets</t>

            <t hangText="Flow Label:">Flow Label value (20 bits)</t>
          </list></t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>The source prefix type mentioned in <xref
      target="IS-IS-extensions-ipv6"/> must be defined.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Network layer Token-based Access Control is part of a security
      solution. It is not, in itself, a complete solution. It acts as a
      pervasive network layer firewall, preventing unauthorized traffic from
      arriving at a destination. However, as in any network, a host is its own
      last bastion of defense; it needs IPsec or TLS-style authorization and
      authorization of its peers, and must refuse traffic that contains the
      authorization token but is in fact malicious.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.ISO.10589.1992" ?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2460" ?>

      <?rfc include="reference.RFC.5308" ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.baker-ipv6-isis-dst-src-routing"?>
    </references>

    <section anchor="log" title="Change Log">
      <t><list style="hanging">
          <t hangText="Initial Version:">February 2013</t>

          <t hangText="updated Version:">August 2013</t>
        </list></t>
    </section>
  </back>
</rfc>