One document matched: draft-haberman-rpsl-reachable-test-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- may be omitted for very short documents -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<!-- these two save paper: start new sections from the same page etc. -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- other categories: bcp, exp, historic, std -->
<rfc category="std" docName="draft-haberman-rpsl-reachable-test-04"
     ipr="trust200902">
  <front>
    <title abbrev="RPSL Pingable Attribute">A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing</title>

    <!-- add 'role="editor"' below for the editors if requiring designation -->

    <author fullname="Brian Haberman" initials="B." role="editor"
            surname="Haberman">
      <organization abbrev="JHU APL">Johns Hopkins University Applied Physics Lab</organization>

      <address>
        <postal>
          <street>11100 Johns Hopkins Road</street>

          <city>Laurel</city>

          <region>MD</region>

          <code>20723-6099</code>

          <country>US</country>
        </postal>

        <email>brian@innovationslab.net</email>

        <phone>+1 443 778 1319</phone>
      </address>
    </author>

    <date month="May" year="2010" />

    <!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->

    <workgroup>IETF</workgroup>

    <abstract>
      <t>The deployment of new IP connectivity typically results in
      intermittent reachability for numerous reasons which are outside the
      scope of this document. In order to aid in
      the debugging of these persistent problems, this document proposes the
      creation of a new Routing Policy Specification Language attribute that
      allows a network to advertise an IP address which is reachable and can
      be used as a target for diagnostic tests (e.g., pings).</t>
    </abstract>
  </front>

  <!-- Main body -->

  <middle>
    <section title="Introduction">
      <t>The deployment of new IP connectivity typically results in
      intermittent reachability for numerous reasons which are outside the
      scope of this document. In order to aid in
      the debugging of these persistent problems, this document proposes the
      creation of a new Routing Policy Specification Language attribute <xref
      target="RFC4012"></xref> that allows a network to advertise an IP
      address which is reachable and can be used as a target for diagnostic
      tests (e.g., pings).</t>

      <t>The goal of this diagnostic address is to provide operators a means
      to advertise selected hosts that can be targets of tests for such common
      issues as reachability and Path MTU discovery.</t>

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

    <section title="RPSL Extension for Diagnostic Address">
      <t>Network operators wishing to provide a diagnostic address for its
      peers, customers, etc. MAY advertise its existence via the Routing
      Policy Specification Language <xref target="RFC4012"></xref> <xref
      target="RFC2622"></xref>. The pingable attribute is a member of the route
      and route6 objects in the RPSL. The definition of the pingable attribute
      is shown in <xref target="rpsl-def"></xref>.</t>

      <figure anchor="rpsl-def" title="pingable attribute specification">
         <artwork><![CDATA[
+-----------+-------------------+--------------+
| Attribute |       Value       |    Type      |
+-----------+-------------------+--------------+
|  pingable | <ipv6-address> or |  optional,   |
|           | <ipv4-address>    | multi-valued |
+-----------+-------------------+--------------+
|  ping-hdl |   <nic-handle>    |  optional,   |
|           |                   | multi-valued |
+-----------+-------------------+--------------+
         ]]></artwork>
      </figure>

      <t>The exact definitions of <ipv4-address> and <nic-handle> can be found in
      <xref target="RFC2622"></xref>, while the definition of <ipv6-address> is in
      <xref target="RFC4012"></xref>.</t>

      <t>The pingable attribute allows a network operator to advertise an IP address
      of a node which should be reachable from outside networks.  This node can be
      used as a destination address for diagnostic tests.  The address specified MUST fall within
      the IP address range advertised in the route/route6 object containing the pingable attribute.
      The ping-hdl provides a link to
      contact information for an entity capable of responding to queries concerning the specified
      IP address. An example of using the
      pingable attribute is shown in <xref target="rpsl-example"></xref>.</t>

      <figure anchor="rpsl-example" title="pingable attribute example">
         <artwork><![CDATA[
route6: 2001:DB8::/32
origin: AS64500
pingable: 2001:DB8::DEAD:BEEF
ping-hdl: OPS4-RIPE
         ]]></artwork>
      </figure>
    </section>

    <section title="Using the RPSL Pingable Attribute">
      <t>The presence of one or more pingable attributes signals to network
      operators that the operator of the target network is providing the
      address(es) for external diagnostic testing. Tests involving the
      advertised address(es) SHOULD be rate limited to no more than ten probes in a
      five minute window unless prior arrangements are made with the maintainer of
      the attribute.</t>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>

    <section title="Security Considerations">
      <t>The use of routing registries based on RPSL requires a significant level of security.
      In-depth discussion of the authentication and authorization capabilities and weaknesses
      within RPSL is discussed in <xref target="RFC2725"></xref>. The application of authentication
      in RPSL is key considering the vulnerabilities that may arise from the abuse of the pingable
      attribute by nefarious actors.  Additional RPSL security issues are discussed in the Security
      Considerations sections of <xref target="RFC2622"></xref> and <xref target="RFC4012"></xref>.</t>

      <t>The publication of this attribute only explicitly signals the availability
      of an ICMP Echo Request/Echo Response service on the specified IP address. The
      operator, at his/her discretion, MAY deploy other services at the same IP address.
      These services may be impacted by the ping service given its publicity via the RPSL.</t>

      <t>While this document specifies that external users of the pingable attribute rate limit
      their probes, there is no guarantee that they will do so. Operators publicizing a pingable attribute
      are encouraged to deploy their own rate limiting for the advertised IP address in order to reduce the
      risk of a denial-of-service attack. Services, protocols, and ports on the advertised IP address should
      be filtered if they are not intended for external users.</t>
    </section>

    <section title="Acknowledgements">
      <t>Randy Bush and David Farmer provided the original concept for the pingable
         attribute and useful comments on preliminary versions of this draft.  Joe Abley
         provided comments that justified moving the attribute to the route/route6 object and
         the inclusion of a point of contact. Larry Blunk, Tony Tauber, David Harrington, Nicolas Williams,
         Sean Turner, and Peter Saint-Andre provided useful comments to improve the document.</t>
    </section>
  </middle>

  <!-- Now all the fluffy stuff -->

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

    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>

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

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

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

    <references title="Informative References"></references>
  </back>
</rfc>