RFC 5943

A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing

📅 published August 2010, from ietf

A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing 🦋

Okay bestie, here's the title block tea ☕

  • RFC number: 5943 💖
  • Authors: B. Haberman, Ed. (JHU APL) 🎀
  • Category: Standards Track ✨
  • Date: August 2010 🌸
  • ISSN: 2070-1721
  • Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract 🧚

Okay so when a brand new IP connection gets set up, it's super common for reachability to be all over the place, and that's for lots of reasons that aren't even this doc's problem 💅 To help debug these stubborn issues, this doc proposes a brand new Routing Policy Specification Language attribute 💜 It lets a network advertise an IP address that's reachable and can be used as a diagnostic test target, like for pings 🏓

Status of This Memo 📜

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. 🌈

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5943. 🔥

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
2.  RPSL Extension for Diagnostic Address . . . . . . . . . . . . . 2
3.  Using the RPSL Pingable Attribute . . . . . . . . . . . . . . . 3
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4

1. Introduction 🌸

New IP connectivity usually comes with intermittent reachability for a bunch of reasons outside this doc's scope 😭 To help debug those annoying persistent problems, this doc proposes a new Routing Policy Specification Language attribute [RFC4012] that lets a network advertise an IP address that's reachable and usable as a target for diagnostic tests (e.g., pings). 🏓

The goal is giving operators a way to advertise selected hosts that can be targets for common stuff like reachability checks and Path MTU discovery. It's giving main character energy 👑

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]. 🎀

2. RPSL Extension for Diagnostic Address 💅

Network operators who want to provide a diagnostic address for their peers, customers, etc. MAY advertise it via the Routing Policy Specification Language [RFC4012] [RFC2622]. The pingable attribute is a member of the route and route6 objects in the RPSL. Here's the definition, shown in Figure 1 ✨

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

                Figure 1: Pingable Attribute Specification

The exact definitions of <ipv4-address> and <nic-handle> are in [RFC2622], and the definition of <ipv6-address> is in [RFC4012]. 🧚

The pingable attribute lets a network operator advertise an IP address for a node that should be reachable from outside networks 🍓 That 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 that contains the pingable attribute. The ping-hdl gives you a link to contact info for whoever can answer questions about that IP address 🫶 Here's an example in Figure 2:

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

                Figure 2: Pingable Attribute Example

3. Using the RPSL Pingable Attribute 🦋

Having one or more pingable attributes tells network operators that the target network's operator is providing those addresses 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. Security Considerations 🔥

🚨 This section is seriously important, bestie. Read it all.

Using routing registries based on RPSL needs a serious level of security. In-depth discussion of the authentication and authorization capabilities and weaknesses within RPSL is in [RFC2725]. Applying authentication in RPSL is key, because the pingable attribute could be abused by nefarious actors and cause real vulnerabilities. Additional RPSL security issues are discussed in the Security Considerations sections of [RFC2622] and [RFC4012]. 💀

Publishing this attribute only explicitly signals that an ICMP Echo Request/Echo Response service is available on the specified IP address. The operator, at his/her discretion, MAY deploy other services at the same IP address. Those services may be impacted by the ping service, since it's publicized via the RPSL. 😭

While this document says external users of the pingable attribute rate limit their probes, there is no guarantee they will actually do so. Operators who publicize a pingable attribute are encouraged to deploy their own rate limiting for the advertised IP address 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. 🛡️

5. Acknowledgements 🫶

Randy Bush and David Farmer came up with the original concept for the pingable attribute and gave useful comments on early versions of this document 👑 Joe Abley's comments justified moving the attribute to the route/route6 object and including a point of contact 🎀 Larry Blunk, Tony Tauber, David Harrington, Nicolas Williams, Sean Turner, and Peter Saint-Andre also gave useful comments that improved the document 💜

6. Normative References 📚

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌸
  • [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. 🧚
  • [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999. 🔥
  • [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, March 2005. 🍓

Author's Address 🎀

Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 US

Phone: +1 443 778 1319 EMail: brian@innovationslab.net 💖

📦 where this page comes from