idnits 2.17.1 draft-jaufeerally-bgp-lg-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 March 2021) is 1120 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8522 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Jaufeerally, Ed. 3 Internet-Draft TBD 4 Intended status: Standards Track 30 March 2021 5 Expires: 1 October 2021 7 An in-band BGP mechanism for looking-glass address discovery 8 draft-jaufeerally-bgp-lg-cap-00 10 Abstract 12 This document specifies a mechanism by which eBGP speakers can 13 propagate a BGP looking glass API endpoint address, in-band within a 14 BGP session. The looking glass API is defined by RFC 8522 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 1 October 2021. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 51 2. Capability wire format . . . . . . . . . . . . . . . . . . . 2 52 3. Usage examples . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Introduction 60 Autonomous systems that peer with one another using the Border 61 Gateway Protocol (RFC 4271 [RFC4271]) do not have an automated way to 62 tell if the prefixes announced over a particular peering link are 63 acceped by the peer. One way in which an AS operator can verify 64 acceptance of routes by a peer is using a looking glass which may be 65 provided by the peer, however this introduces manual toil in the 66 operation and turnup of peering links. 68 This document proposes a mechanism building on the looking glass API 69 defined in RFC 8522 [RFC8522] to enable the automatic discovery of 70 the looking glass endpoint, and therefore enable the automated 71 probing of announcement acceptance by a peer, for instance. 73 The mechanism by which this is achieved is to intoduce a new BGP 74 capability which is sent in an OPEN message at session establishment 75 time. 77 1.1. Requirements Language 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 2. Capability wire format 85 The capability is composed of two parts, the header and payload. 87 The following shows the wire format of the capability payload header: 89 0 1 2 3 4 5 6 7 90 +-+-+-+-+-+-+-+-+ 91 |Version| Type | ... varies based on type ... 92 +-+-+-+-+-+-+-+-+ 94 Figure 1 96 This document defines version 1 of the capability, and as such the 97 Version field MUST be set to 1. Implementations MUST discard the 98 capability if the version number is not recognized. 100 Type can be set to one of two values: 102 +-------+--------------------+ 103 | Value | Description | 104 +=======+====================+ 105 | 1 | On router endpoint | 106 +-------+--------------------+ 107 | 2 | URL endpoint | 108 +-------+--------------------+ 110 Table 1: Type field in header 112 When the type field is set to 1, the capability MUST contain the 113 following two bytes after the header which represent the TCP port: 115 0 7 8 15 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | tcp_port | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 2 122 The tcp_port field is a 16-bit unsigned integer encoded in network 123 byte order, which represents the TCP port on the peer BGP speaker 124 (i.e. the BGP peer IP address) that the looking glass is available 125 at. 127 When the type field is set to two the rest of the capability contains 128 an ASCII encoded string representing a URL where the looking glass 129 endpoint can be found. This URL MUST conform to RFC 3986 [RFC3986] 131 In both cases, the looking glass endpoint advertised MUST conform to 132 RFC 8522 [RFC8522]. 134 3. Usage examples 136 Between peers who have a direct BGP peering connection this capabilty 137 will allow for direct probing of the routing state of the peer AS to 138 determine if advertised routes were accepted. 140 On an internet exchange, the route server can advertise this 141 capability to expose the route server looking glass, which whilest 142 not providing information on if peers have accepted the routes, 143 provides a way to check that routes are being propagated to peers on 144 the route server. 146 4. IANA Considerations 148 This memo requests a BGP capability code from IANA in the 64 through 149 127 range using the first come first served policy defined by RFC 150 5492 [RFC5492]. 152 5. Security Considerations 154 This draft proposes a mechanism for providing more easily automatable 155 access to a looking glass interface operated by a network. The scope 156 of the dissemination of these looking glass adresses is to direct 157 peers which are presumed to have an interest in querying the network 158 reachability information, for example as part of debugging. 160 Many network operators already provide looking glass services to the 161 general public, however these are usually not standardized in their 162 interfaces, and moreover, are not discoverable in an automated way 163 which makes scalability difficult, and thus this draft 164 programatically propagates that information. 166 Operators MUST treat connections to the looking glass as untrusted. 167 Operators SHOULD perform apppropriate rate-limiting and MAY deny 168 abusive clients as per their own policy 170 Operators may operate the looking glass with an IP access control 171 list in cases where access is intended only for the peer, however 172 this is discouraged as running a public facing looking glass brings 173 the benefit that anyone can use it to debug network issues. 175 6. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, 179 DOI 10.17487/RFC2119, March 1997, 180 . 182 [RFC8522] Stubbig, M., "Looking Glass Command Set", RFC 8522, 183 DOI 10.17487/RFC8522, February 2019, 184 . 186 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 187 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 188 DOI 10.17487/RFC4271, January 2006, 189 . 191 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 192 Resource Identifier (URI): Generic Syntax", STD 66, 193 RFC 3986, DOI 10.17487/RFC3986, January 2005, 194 . 196 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 197 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 198 2009, . 200 Author's Address 202 Rayhaan Jaufeerally (editor) 203 TBD 204 CH- Zurich 205 Swiss Confederation 207 Email: rayhaan+ietf@rayhaan.ch