Internet Engineering Task Force R. Jaufeerally, Ed.
Internet-Draft TBD
Intended status: Standards Track 30 March 2021
Expires: 1 October 2021
An in-band BGP mechanism for looking-glass address discovery
draft-jaufeerally-bgp-lg-cap-00
Abstract
This document specifies a mechanism by which eBGP speakers can
propagate a BGP looking glass API endpoint address, in-band within a
BGP session. The looking glass API is defined by RFC 8522
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 1 October 2021.
Copyright Notice
Copyright (c) 2021 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.
Jaufeerally Expires 1 October 2021 [Page 1]
Internet-Draft Abbreviated Title March 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Capability wire format . . . . . . . . . . . . . . . . . . . 2
3. Usage examples . . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Autonomous systems that peer with one another using the Border
Gateway Protocol (RFC 4271 [RFC4271]) do not have an automated way to
tell if the prefixes announced over a particular peering link are
acceped by the peer. One way in which an AS operator can verify
acceptance of routes by a peer is using a looking glass which may be
provided by the peer, however this introduces manual toil in the
operation and turnup of peering links.
This document proposes a mechanism building on the looking glass API
defined in RFC 8522 [RFC8522] to enable the automatic discovery of
the looking glass endpoint, and therefore enable the automated
probing of announcement acceptance by a peer, for instance.
The mechanism by which this is achieved is to intoduce a new BGP
capability which is sent in an OPEN message at session establishment
time.
1.1. 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 [RFC2119].
2. Capability wire format
The capability is composed of two parts, the header and payload.
The following shows the wire format of the capability payload header:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Version| Type | ... varies based on type ...
+-+-+-+-+-+-+-+-+
Figure 1
Jaufeerally Expires 1 October 2021 [Page 2]
Internet-Draft Abbreviated Title March 2021
This document defines version 1 of the capability, and as such the
Version field MUST be set to 1. Implementations MUST discard the
capability if the version number is not recognized.
Type can be set to one of two values:
+-------+--------------------+
| Value | Description |
+=======+====================+
| 1 | On router endpoint |
+-------+--------------------+
| 2 | URL endpoint |
+-------+--------------------+
Table 1: Type field in header
When the type field is set to 1, the capability MUST contain the
following two bytes after the header which represent the TCP port:
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tcp_port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The tcp_port field is a 16-bit unsigned integer encoded in network
byte order, which represents the TCP port on the peer BGP speaker
(i.e. the BGP peer IP address) that the looking glass is available
at.
When the type field is set to two the rest of the capability contains
an ASCII encoded string representing a URL where the looking glass
endpoint can be found. This URL MUST conform to RFC 3986 [RFC3986]
In both cases, the looking glass endpoint advertised MUST conform to
RFC 8522 [RFC8522].
3. Usage examples
Between peers who have a direct BGP peering connection this capabilty
will allow for direct probing of the routing state of the peer AS to
determine if advertised routes were accepted.
Jaufeerally Expires 1 October 2021 [Page 3]
Internet-Draft Abbreviated Title March 2021
On an internet exchange, the route server can advertise this
capability to expose the route server looking glass, which whilest
not providing information on if peers have accepted the routes,
provides a way to check that routes are being propagated to peers on
the route server.
4. IANA Considerations
This memo requests a BGP capability code from IANA in the 64 through
127 range using the first come first served policy defined by RFC
5492 [RFC5492].
5. Security Considerations
This draft proposes a mechanism for providing more easily automatable
access to a looking glass interface operated by a network. The scope
of the dissemination of these looking glass adresses is to direct
peers which are presumed to have an interest in querying the network
reachability information, for example as part of debugging.
Many network operators already provide looking glass services to the
general public, however these are usually not standardized in their
interfaces, and moreover, are not discoverable in an automated way
which makes scalability difficult, and thus this draft
programatically propagates that information.
Operators MUST treat connections to the looking glass as untrusted.
Operators SHOULD perform apppropriate rate-limiting and MAY deny
abusive clients as per their own policy
Operators may operate the looking glass with an IP access control
list in cases where access is intended only for the peer, however
this is discouraged as running a public facing looking glass brings
the benefit that anyone can use it to debug network issues.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8522] Stubbig, M., "Looking Glass Command Set", RFC 8522,
DOI 10.17487/RFC8522, February 2019,
<https://www.rfc-editor.org/info/rfc8522>.
Jaufeerally Expires 1 October 2021 [Page 4]
Internet-Draft Abbreviated Title March 2021
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>.
Author's Address
Rayhaan Jaufeerally (editor)
TBD
CH- Zurich
Swiss Confederation
Email: rayhaan+ietf@rayhaan.ch
Jaufeerally Expires 1 October 2021 [Page 5]