idnits 2.17.1 draft-jaufeerally-bgp-lg-cap-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4271], [RFC8522]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2021) is 1016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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: Informational July 2021 5 Expires: 26 January 2022 7 An in-band BGP mechanism for looking-glass address discovery 8 draft-jaufeerally-bgp-lg-cap-01 10 Abstract 12 Autonomous Systems (ASes) that peer with one another using the Border 13 Gateway Protocol (BGP) RFC 4271 [RFC4271] do not have an automated 14 way to tell if the prefixes announced over a particular peering link 15 are acceped by the peer. One way in which an AS operator can verify 16 acceptance of routes by a peer is using a looking glass which may be 17 provided by the peer, however this introduces manual toil in the 18 operation and turnup of peering links, and does not allow for 19 continued validation to ensure there are no regressions. Looking 20 glasses are often manually found by browsing the website of the peer 21 or via a database of peering participants. 23 This document proposes a new in-band mechanism for transmitting 24 administrative data between BGP peers, and defines one such use case 25 for propagating looking glass addresses. This is done via a new 26 Address Family Identifier (AFI) which carries a message that we 27 define here, inside the Multi Protocol (MP_REACH and MP_UNREACH) path 28 attribute 30 The looking glass that we expose via the proposed mechanism conforms 31 to that defined in RFC 8522 [RFC8522]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 2 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 68 2. Advertising support for the administrative message . . . . . 3 69 3. Format of the administrative message . . . . . . . . . . . . 3 70 4. Looking glass payload . . . . . . . . . . . . . . . . . . . . 3 71 5. Propoagation of looking glass information . . . . . . . . . . 4 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 9.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 In this document we introduce a new Address Family Identifier (AFI) 83 to carry an administrative message via the existing BGP update 84 message that is defined in RFC 4271 [RFC4271] 86 When a peer signals support for this AFI, we define a mechanism 87 through which an administrative message contained within BGP UPDATE 88 path attributes can be used to propagate inforamation such as but not 89 limited to a looking glass URL. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Advertising support for the administrative message 99 Peers that support sending and receiving administrative messages via 100 this mechanism MUST advertise support by sending a multiprotocol 101 capability advertisment, as defined in RFC 4760 section 8 [RFC4760]. 102 The AFI used is that assigned by IANA (Note to editor: insert the 103 actual value here once assigned). 105 A peer SHOULD only send the messages defined in this document to a 106 peer which has advertised support for the administrative message AFI. 108 3. Format of the administrative message 110 The administrative message is transmitted through a BGP UPDATE 111 message containing a multiprotocol reach or multiprotocol unreach 112 path attribute with the AFI set to the AFI for this document (Note to 113 editor: insert value here after assignment from IANA). The SAFI 114 field SHOULD be set to 0 and MUST be ignored by the recipient, as it 115 is unused in this specification, and is reserved for future use. 117 The payload format is as follows: 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | version | type | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | payload (variable) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 1 129 Figure 1 shows the layout of the administrative message which is to 130 be contained within the multiprotocol reahable (MP_REACH) and 131 multiprotocol unreachable (MP_UNREACH) path attributes. Each 132 submessage type will define its own semantics of when MP_REACH and / 133 or MP_UNREACH is to be used. 135 4. Looking glass payload 137 The looking glass mechanism is disemminated using a administrative 138 message with a type of 1. 140 The looking glass mechanism supports advertising to a BGP peer an 141 HTTP endpoint at which looking glass operations such as but not 142 limited to: IP prefix lookups in the RIB of the peer, ping, 143 traceroute, etc. This endpoint, in version 1 of the looking glass 144 protocol, MUST conform to the standard set out in RFC 8522 [RFC8522]. 146 The looking glass address can be specified in one of two ways: (1) on 147 the BGP peer interface itself (i.e. the looking glass can be reached 148 on the address of the BGP peer router itself), (2) on a URL specified 149 within the message itself. 151 0 1 2 3 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | version | ASN | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | URL (variable length)... | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 2: Looking glass message format 161 Figure 2 shows the wire format of the administrative message. The 162 first byte is the looking glass administrative payload version number 163 which MUST be set to 1. This may be updated in future revisions to 164 define new functionality, so software MUST ignore paylaods with 165 unrecognized version numbers. ASN MUST be set to the autonomous 166 system number of the network that is operating the looking glass. 167 That is to say, if an AS is announcing its own looking glass this 168 should be the ASN which is announced in the BGP OPEN message. On the 169 other hand, if this is a looking glass address propagated from 170 another peer, this MUST be the ASN of the network originating the 171 looking glass message. See Section 5 for details on how propagation 172 is handled. 174 The URL section is a variable length field which contains the ASCII 175 encoded HTTP(s) endpoint of the looking glass. 177 5. Propoagation of looking glass information 179 While it is useful to have a looking glass to test the connectivity 180 and route acceptance of a direct peer, it is oftentimes desirable to 181 know if an "upstream" peer has accepted the route as well. Consider 182 the case of a tier-2 ISP which has several uplinks to tier-1 ISPs. 183 In this case, the customer of a tier-2 ISP would benefit to know 184 whether their routes have been accepted by the tier-1 upstream peers, 185 which may have different filtering policies, and thus have a 186 different set of accepted routes. 188 In the base case to advertise the looking glass of the ASN that is 189 running the BGP speaker, the speaker sets the ASN field to the ASN of 190 the speaker itself. 192 A BGP speaker SHOULD forward looking glass addresses of a peer P_a to 193 a peer P_b when a route from P_b has been announced to P_a. This 194 MUST only be done if P_a has advertised the looking glass address to 195 the BGP speaker making this decision, and the forwarded URL MUST be 196 the one which P_a has advertised. 198 6. Acknowledgements 200 The authors would like to thank the members of the GROW WG for their 201 feedback on this draft. (Note to the editor: update this in future 202 revisions of the draft). 204 7. IANA Considerations 206 We request IANA to allocate a new address family identifier for the 207 administrative message, (Note to editor: fill in here after getting 208 an assignment) 210 We also require a registry of types that can be contained within the 211 administrative message type. This document allocates the first 212 administrative message type of 1 to be used for the looking glass 213 message. (Note to editor: add more details here.) 215 8. Security Considerations 217 This draft proposes a mechanism for providing more easily automatable 218 access to a looking glass interface operated by a network. The scope 219 of the dissemination of these looking glass adresses is to direct 220 peers which are presumed to have an interest in querying the network 221 reachability information, for example as part of debugging. 223 Many network operators already provide looking glass services to the 224 general public, however these are usually not standardized in their 225 interfaces, and moreover, are not discoverable in an automated way 226 which makes scalability difficult, and thus this draft 227 programatically propagates that information. 229 Operators MUST treat connections to the looking glass as untrusted. 230 Operators SHOULD perform apppropriate rate-limiting and MAY deny 231 abusive clients as per their own policy 233 Operators may operate the looking glass with an IP access control 234 list in cases where access is intended only for the peer, however 235 this is discouraged as running a public facing looking glass brings 236 the benefit that anyone can use it to debug network issues. 238 9. References 239 9.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 247 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 248 DOI 10.17487/RFC4271, January 2006, 249 . 251 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 252 "Multiprotocol Extensions for BGP-4", RFC 4760, 253 DOI 10.17487/RFC4760, January 2007, 254 . 256 [RFC8522] Stubbig, M., "Looking Glass Command Set", RFC 8522, 257 DOI 10.17487/RFC8522, February 2019, 258 . 260 9.2. Informative References 262 Author's Address 264 Rayhaan Jaufeerally (editor) 265 TBD 266 CH- Zurich 267 Switzerland 269 Email: ietf@rayhaan.ch