A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing
draft-haberman-rpsl-reachable-test-04

Abstract

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).

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on November 28, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  RPSL Extension for Diagnostic Address
3.  Using the RPSL Pingable Attribute
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address

1.  Introduction

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 [RFC4012] (Blunk, L., Damas, J., Parent, F., and A. Robachevsky, “Routing Policy Specification Language next generation (RPSLng),” March 2005.) 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).

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.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  RPSL Extension for Diagnostic Address

Network operators wishing to provide a diagnostic address for its peers, customers, etc. MAY advertise its existence via the Routing Policy Specification Language [RFC4012] (Blunk, L., Damas, J., Parent, F., and A. Robachevsky, “Routing Policy Specification Language next generation (RPSLng),” March 2005.) [RFC2622] (Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, “Routing Policy Specification Language (RPSL),” June 1999.). The pingable attribute is a member of the route and route6 objects in the RPSL. The definition of the pingable attribute is shown in Figure 1 (pingable attribute specification).

+-----------+-------------------+--------------+
| Attribute |       Value       |    Type      |
+-----------+-------------------+--------------+
|  pingable | <ipv6-address> or |  optional,   |
|           | <ipv4-address>    | multi-valued |
+-----------+-------------------+--------------+
|  ping-hdl |   <nic-handle>    |  optional,   |
|           |                   | multi-valued |
+-----------+-------------------+--------------+

The exact definitions of <ipv4-address> and <nic-handle> can be found in [RFC2622] (Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, “Routing Policy Specification Language (RPSL),” June 1999.), while the definition of <ipv6-address> is in [RFC4012] (Blunk, L., Damas, J., Parent, F., and A. Robachevsky, “Routing Policy Specification Language next generation (RPSLng),” March 2005.).

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 Figure 2 (pingable attribute example).

route6: 2001:DB8::/32
origin: AS64500
pingable: 2001:DB8::DEAD:BEEF
ping-hdl: OPS4-RIPE

3.  Using the RPSL Pingable Attribute

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.

4.  IANA Considerations

None.

5.  Security Considerations

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 [RFC2725] (Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, “Routing Policy System Security,” December 1999.). 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 [RFC2622] (Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, “Routing Policy Specification Language (RPSL),” June 1999.) and [RFC4012] (Blunk, L., Damas, J., Parent, F., and A. Robachevsky, “Routing Policy Specification Language next generation (RPSLng),” March 2005.).

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.

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.

6.  Acknowledgements

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.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address