idnits 2.17.1 draft-abraitis-bgp-version-capability-05.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2020) is 1495 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8174' is mentioned on line 76, but not defined == Missing Reference: 'RFC5492' is mentioned on line 79, but not defined == Missing Reference: 'RFC5082' is mentioned on line 197, but not defined == Unused Reference: 'RFC3552' is defined on line 218, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Abraitis 3 Internet-Draft Hostinger 4 Intended status: Informational March 24, 2020 5 Expires: September 25, 2020 7 Version Capability for BGP 8 draft-abraitis-bgp-version-capability-05 10 Abstract 12 In this document, we introduce a new BGP capability that allows the 13 advertisement of a BGP speaker's version. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 25, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification of Requirements . . . . . . . . . . . . . . . . 2 51 3. Version Capability . . . . . . . . . . . . . . . . . . . . . 2 52 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 57 7.2. Informative References . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 In modern data center designs, we tend to have conventional hosts 63 participating in the routing process. And the fleet of hosts has 64 different versions of routing daemon. This means that 65 troubleshooting is a crucial part to quickly identify the root cause. 66 This document introduces the new BGP capability to advertise the 67 version of the routing daemon. 69 2. Specification of Requirements 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 73 "OPTIONAL" in this document are to be interpreted as described in BCP 74 14 [RFC2119] [RFC8174] when, and only when, they appear in all 75 capitals, as shown here. 77 3. Version Capability 79 The Version Capability is a new BGP capability [RFC5492]. The 80 implementation is specific to the vendor. The version is 81 unstructured and can be defined in any format the vendor decides. 83 The length of the version SHOULD be limited to 64 bytes. This is the 84 limit to allow other capabilities as much space as they require. The 85 version MUST NOT be empty. 87 This capability is OPTIONAL. The vendor MUST implement a capability 88 switch to enable or disable it. 90 In case you reached 255 bytes of capabilities, you can disable this 91 capability. The capability is designed more to non-production 92 environments where you need more visibility for troubleshooting 93 purposes. It's RECOMMENDED to turn it only inside a single 94 Autonomous System domain or Autonomous System Confederations. 96 Such protocols like LLDP, CDP can provide the same information as 97 well, but in containerized environments, it's very hard and NOT 98 RECOMMENDED run background processes. To minimize operational costs 99 it would help having all the necessary information in place. 101 +--------------------------------+ 102 | Version Length (1 octet) | 103 +--------------------------------+ 104 | Version (variable) | 105 +--------------------------------+ 107 Figure 1 109 Version Length: 111 The number of characters in the Version 113 Version: 115 The Version encoded via UTF-8 117 4. Operation 119 The Version capability MUST only be used for displaying the version 120 of a speaker to make troubleshooting easier. You have a bunch of 121 routers with a number of upstreams each. All of them are with a 122 different operating system and routing daemon installed. Assuming 123 that a specific feature is not working or a bug which is not fixed in 124 an appropriate version, would allow us to quickly identify the 125 pattern which versions are affected. 127 Enabling this capability REQUIRED bouncing all existing BGP sessions. 128 It MUST be explicitly configured to advertise the Version capability. 130 Below is an example of implementation in [FRRouting] how it looks 131 like with version advertised by a BGP sender: 133 :~# vtysh -c 'show ip bgp summary failed' 134 ... 135 Neighbor EstdCnt DropCnt ResetTime Reason 136 198.51.100.2 3 3 00:00:35 Waiting for peer OPEN (n/a) 137 198.51.100.3 3 3 00:01:12 Peer closed the session (FRRouting 7.2-b3ac21114g) 138 198.51.100.4 3 3 00:00:14 Peer closed the session (FRRouting 7.3-g4c566878f) 139 198.51.100.5 3 3 00:00:45 Peer closed the session (FRRouting 7.4-a25sg503g2) 140 ... 142 Figure 2 144 :~# vtysh -c 'show ip bgp neighbors 198.51.100.1 json' \ 145 > | jq '."198.51.100.1".neighborCapabilities.versions' 146 { 147 "advertisedVersion": "FRRouting 7.2-dev-MyOwnFRRVersion", 148 "receivedVersion": "FRRouting 7.2-dev-MyOwnFRRVersion-gc68bb14" 149 } 151 Figure 3 153 5. IANA Considerations 155 IANA maintains the "Border Gateway Protocol (BGP) Parameters" 156 registry with a subregistry called "Capabilities Codes". IANA is 157 requested to assign a capability number from the First Come First 158 Served range for the Version Capability in this document as follows: 160 +-------+-----------------+-----------------------------------------+ 161 | Value | Description | Reference | 162 +-------+-----------------+-----------------------------------------+ 163 | TBD | Version | [draft-abraitis-bgp-version-capability] | 164 | | Capability | | 165 +-------+-----------------+-----------------------------------------+ 167 Table 1: Version Capability 169 6. Security Considerations 171 The Version Capability can be treated as sensitive information, thus 172 it would be easier for an attacker to exploit by knowing the specific 173 version of the BGP speaker. This information can be gathered in BGP 174 OPEN messages. 176 The Version Capability MUST be configurable with a vendor-specific 177 knob to be able to enable or disable the capability. The vendor 178 might implement to disable this capability per neighbor. 180 It would be safe to enable this for iBGP or inside the same tenant 181 where you have full control and the BGP speaker is behind exit 182 points. 184 The Version Capability information can be gathered in BGP OPEN 185 messages. 187 Modifying the information advertised by a router might lead to 188 attacks including bogus software upgrades and also might mask the 189 causes of faults in the network. 191 Advertising which versions of code and from which vendor it comes may 192 facilitate a number of social-engineering attacks. A lot of BGP 193 implementations leave TCP/179 open and this could lead to sensitive 194 information disclosure. This capability is NOT RECOMMENDED for eBGP 195 use. 197 Sensitive information leaks can be minimized by using the [RFC5082] 198 mechanism or firewalls to filter out TCP 179 port from untrusted 199 networks. This capability can be disabled per neighbor, thus the 200 sensitive information can't be disclosed to untrusted neighbors. 202 7. References 204 7.1. Normative References 206 [FRRouting] 207 Abraitis, D., "FRRouting - BGP Version Capability", 2019, 208 . 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, 213 DOI 10.17487/RFC2119, March 1997, 214 . 216 7.2. Informative References 218 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 219 Text on Security Considerations", BCP 72, RFC 3552, 220 DOI 10.17487/RFC3552, July 2003, 221 . 223 Author's Address 225 Donatas Abraitis 226 Hostinger 227 Jonavos g. 60C 228 Kaunas 44192 229 LT 231 Phone: +370 614 18958 232 Email: donatas.abraitis@hostinger.com