idnits 2.17.1 draft-abraitis-bgp-version-capability-03.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 (December 1, 2019) is 1601 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 161, but not defined == Unused Reference: 'RFC3552' is defined on line 182, but no explicit reference was found in the text Summary: 0 errors (**), 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 December 1, 2019 5 Expires: June 3, 2020 7 Version Capability for BGP 8 draft-abraitis-bgp-version-capability-03 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 June 3, 2020. 32 Copyright Notice 34 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 3 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 57 7.2. Informative References . . . . . . . . . . . . . . . . . 4 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 new BGP capability to advertise the version 67 of 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 +--------------------------------+ 84 | Version Length (1 octet) | 85 +--------------------------------+ 86 | Version (variable) | 87 +--------------------------------+ 89 Figure 1 91 Version Length: 93 The number of characters in the Version 95 Version: 97 The Version encoded via UTF-8 99 4. Operation 101 The Version capability MUST only be used for displaying the version 102 of a speaker in order to make troubleshooting easier. You have a 103 bunch of routers with a number of upstreams each. All of them are 104 with a different operating system and routing daemon installed. 105 Assuming that a specific feature is not working or a bug which is not 106 fixed in an appropriate version, would allow us to quickly identify 107 the pattern which versions are affected. Below is an example of 108 implementation in [FRRouting] how it looks like with version 109 advertised by a BGP sender: 111 :~# vtysh -c 'show ip bgp neighbors 198.51.100.1 json' \ 112 > | jq '."198.51.100.1".neighborCapabilities.versions' 113 { 114 "advertisedVersion": "FRRouting 7.2-dev-MyOwnFRRVersion", 115 "receivedVersion": "FRRouting 7.2-dev-MyOwnFRRVersion-gc68bb14" 116 } 118 Figure 2 120 5. IANA Considerations 122 IANA maintains the "Border Gateway Protocol (BGP) Parameters" 123 registry with a subregistry called "Capabilities Codes". IANA is 124 requested to assign a capability number from the First Come First 125 Served range for the Version Capability in this document as follows: 127 +-------+-----------------+-----------------------------------------+ 128 | Value | Description | Reference | 129 +-------+-----------------+-----------------------------------------+ 130 | TBD | Version | [draft-abraitis-bgp-version-capability] | 131 | | Capability | | 132 +-------+-----------------+-----------------------------------------+ 134 Table 1: Version Capability 136 6. Security Considerations 138 The Version Capability can be treated as sensitive information, thus 139 it would be easier for an attacker to exploit by knowing the specific 140 version of the BGP speaker. This information can be gathered in BGP 141 OPEN messages. 143 The Version Capability MUST be configurable with a vendor-specific 144 knob to be able to enable or disable the capability. The vendor 145 might implement to disable this capability per neighbor. 147 It would be safe to enable this for iBGP or inside the same tenant 148 where you have full control and the BGP speaker is behind exit 149 points. 151 The Version Capability information can be gathered in BGP OPEN 152 messages. 154 Modifying the information advertised by a router might lead to 155 attacks including bogus software upgrades and also might mask the 156 causes of faults in the network. 158 Advertising which versions of code and from which vendor it comes may 159 facilitate a number of social-engineering attacks. 161 Sensitive information leaks can be minimized by using the [RFC5082] 162 mechanism or firewalls to filter out TCP 179 port from untrusted 163 networks. This capability can be disabled per neighbor, thus the 164 sensitive information can't be disclosed to untrusted neighbors. 166 7. References 168 7.1. Normative References 170 [FRRouting] 171 Abraitis, D., "FRRouting - BGP Version Capability", 2019, 172 . 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, 177 DOI 10.17487/RFC2119, March 1997, 178 . 180 7.2. Informative References 182 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 183 Text on Security Considerations", BCP 72, RFC 3552, 184 DOI 10.17487/RFC3552, July 2003, 185 . 187 Author's Address 189 Donatas Abraitis 190 Hostinger 191 Jonavos g. 60C 192 Kaunas 44192 193 LT 195 Phone: +370 614 18958 196 Email: donatas.abraitis@hostinger.com