Providing Next External Hop Path Information to End Hosts
draft-jaufeerally-nexthop-path-info-00

Abstract

The aim of this document is to define an interface through which an Autonomous System (AS) can disseminate information about forwarding of packets to the next hop outside the AS, to devices within its network. This information can be used to make path aware routing decisions, either by being aware of the default route packets will take when traversing the AS, or by using other mechanisms to control the path packets which is out of the scope of this document.

Requirements Language

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 RFC 2119.

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 https://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 June 13, 2019.

Copyright Notice

Copyright (c) 2018 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 (https://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. Detection of Path Aware Functionality
• 3. The Path Service
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

The current state of the internet is such that routing decisions are made by the network operator, and the end user has no a priori information about network paths. It is possible to manually find information about paths a posteriori using tools such as traceroute.

There exists unstandardized out of band mechanisms such as looking glasses and specialized tools like NLNOG RING that allow for customizable introspection of the network control and data plane. These tools provide valuable information to network engineers, and enthusiastic end users to ascertain information about forwarding routes which packets are nominally following.

This document defines a standardized interface to provide network path information to end hosts, routers, and other devices within a network. This path awareness can be used to optimize use of network resources by the end host, for example allowing programmatic decisions on which links to use for a given packet.

The implementation strategy we define is a mechanism to bootstrap devices within an AS with the information required to obtain path awareness from the network control plane. In addition, we define a standard format for the interchange of path information in this context.

2. Detection of Path Aware Functionality

In order for an end host to make use of the path aware functionality in a network, the host needs to detect that the network supports such features. To make hosts aware of these features we use an extension to the provisioning domain architecture to advertise a service which can provide network path information.

We define a new PvD key, "x-52759-pan" which contains information about the path aware network services. Specifically, in this draft we use this vehicle to distribute the service endpoint address for the path resolution service. The PvD contents of this attribute are defined as follows:

{
    "version": "draft-irtf-panrg-nexthop-path-info-00",
    "url": "https://path-server.pan.rayhaan.net/"
}

Example contents of the "x-52759-pan" attribute in the PvD JSON document.

Figure 1

The url parameter MUST be resolvable by the client using the default name resolution services available in the network, and SHOULD also be resolvable globally to facilitate usage by hosts using alternative name resolution services.

3. The Path Service

The Path Service provides a uniform API through which path information can be obtained. We define in this section the functionality which this service must provide, and how it will be accessed by clients.

Implementations of this draft MUST support IPv6 as AF parameter, and MAY also support IPv4.

The data type for returned data in this service is determined by the HTTP "accept" header which is provided by the client. Implementations of this draft MUST support the "application/json" content type and MAY support others which are out of scope of this document.

When the requested content type is "application/json" the following schema MUST be used to return data to the client.

{
"dest_prefix": "192.0.2.0/24",
"paths": [{
        "id": "0x1",
        "link_name": "prov-1",
        "AS_Path": [64496, 64497, 64498]
    },
    {
        "id": "0x2",
        "link_name": "IX-CH",
        "AS_Path": [64496, 64498]
    }
]
}

Figure 2

When all the routes are requested the format of data returned is as follows.

{
  "links": [
    {
      "id": "0x1",
      "link_name": "prov-1",
      "routes": [
        {
          "prefix": "192.0.2.0/24",
          "AS_Path": [64496, 64497, 64498]
        }
      ]
    },
    {
      "id": "0x2",
      "link_name": "IX-CH",
      "routes": [
        {
          "prefix": "192.0.2.0/24",
          "AS_Path": [64496, 64498]
        }
      ]
    }
  ]
}

Additionally a diff since a certain timestamp MAY be provided by an implementation of this draft. Implementations that chose to provide this functionality MUST do so by accepting the "since" query parameter on the "/route/all" URL with a timestamp of seconds since January 1, 1970. The server will then return routes which have been added and / or removed since the specified timestamp. The format is the same as the full route schema, except for two additional fields, as specified below.

The objects contained within the "links" array MAY contain a "delta" key which MUST be either "add" or "del". This means the link was added or removed since the requested "since" time respectively. Furthermore individual route objects contained within the "routes" key MUST contain a "delta" key which MUST be either "add" or "del" if the route has been added or removed over that link respectively. If a route has not changed it MUST NOT be included in the diff message.

4. Acknowledgements

The authors would like to thank Brian Trammell and Milan Pandurov for their valuable input and feedback.

5. IANA Considerations

IANA is asked to allocate a new string in the registry entitled "Additional Information PvD Keys" for use in the provisioning domain additional information JSON document.

6. Security Considerations

The explicit knowledge of paths within a network by end devices is not considered a security risk, since this information can be obtained through other mechanisms, albeit less reliably and in a non uniform manner. Moreover, should a service provider not wish to reveal the existence of a link, there is no obligation to provide such information in the data returned, however the authors believe having more transparency in the network is better for the ecosystem as a whole.

This internet draft does not specify any security mechanisms for ensuring the authenticity of information returned from the route service, but such a mechanism may be proposed at a later point in time.

7. References

7.1. Normative References

7.2. Informative References

Author's Address