idnits 2.17.1 draft-ietf-idr-bgp-autoconf-considerations-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (18 January 2022) is 800 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-acee-idr-lldp-peer-discovery-10 == Outdated reference: A later version (-12) exists of draft-ietf-idr-bgp-bfd-strict-mode-06 == Outdated reference: A later version (-12) exists of draft-ietf-lsvr-l3dl-08 == Outdated reference: A later version (-06) exists of draft-ietf-lsvr-l3dl-signing-03 == Outdated reference: A later version (-05) exists of draft-ietf-lsvr-l3dl-ulpc-02 == Outdated reference: A later version (-08) exists of draft-raszuk-idr-bgp-auto-discovery-07 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Arrcus, Inc. & Internet Initiative Japan 4 Intended status: Informational J. Dong 5 Expires: 22 July 2022 Huawei Technologies 6 J. Haas, Ed. 7 Juniper Networks 8 W. Kumari, Ed. 9 Google 10 18 January 2022 12 Requirements and Considerations in BGP Peer Auto-Configuration 13 draft-ietf-idr-bgp-autoconf-considerations-02 15 Abstract 17 This draft is an exploration of the requirements, the alternatives, 18 and trade-offs in BGP peer auto-discovery at various layers in the 19 stack. It is based on discussions in the IDR Working Group BGP 20 Autoconf Design Team. The current target environment is the 21 datacenter. 23 This document is not intended to become an RFC. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in BCP 14 [RFC2119] 30 [RFC8174] when, and only when, they appear in all capitals, as shown 31 here. 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 22 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Design Team Determinations . . . . . . . . . . . . . . . . . 3 68 2.1. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.3. BGP Auto-Discovery Protocol State Requirements . . . . . 3 71 2.3.1. BGP Auto-Discovery Protocol State . . . . . . . . . . 4 72 2.3.2. BGP Session Protocol State . . . . . . . . . . . . . 4 73 2.4. BGP Auto-Discovery Protocol Transport Requirements . . . 4 74 2.5. Operator Configuration . . . . . . . . . . . . . . . . . 5 75 3. Design Principle Considerations . . . . . . . . . . . . . . . 5 76 3.1. Transport Considerations . . . . . . . . . . . . . . . . 5 77 3.2. Auto-Discovery Protocol Timing Considerations . . . . . . 6 78 3.3. Relationship with BGP . . . . . . . . . . . . . . . . . . 6 79 3.4. Session Selection Considerations . . . . . . . . . . . . 6 80 3.5. Session Stability Considerations . . . . . . . . . . . . 7 81 3.6. Operational Trust Considerations . . . . . . . . . . . . 7 82 3.7. Error Handling Considerations . . . . . . . . . . . . . . 9 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 5.1. BGP Transport Security Considerations . . . . . . . . . . 10 86 5.2. Auto-discovery Protocol Considerations . . . . . . . . . 10 87 5.2.1. Potential Scopes of an Auto-discovery Protocol . . . 10 88 5.2.2. Desired Security Properties of the Auto-discovery 89 Protocols . . . . . . . . . . . . . . . . . . . . . . 11 90 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 7.2. Informative References . . . . . . . . . . . . . . . . . 12 94 Appendix A. Analysis of Candidate Approaches . . . . . . . . . . 14 95 A.1. BGP Peer Discovery at Layer Two . . . . . . . . . . . . . 14 96 A.1.1. LLDP based Approach . . . . . . . . . . . . . . . . . 15 97 A.1.2. L3DL based Approach . . . . . . . . . . . . . . . . . 15 99 A.2. Link-Local Discovery . . . . . . . . . . . . . . . . . . 16 100 A.3. BGP peer Discovery at Layer Three . . . . . . . . . . . . 16 101 A.3.1. New BGP Hello Message based Approach . . . . . . . . 17 102 A.3.2. BGP OPEN Message based Approach . . . . . . . . . . . 17 103 A.3.3. Bootstrapping BGP via BGP . . . . . . . . . . . . . . 18 104 A.3.4. Bootstrapping BGP via OSPF . . . . . . . . . . . . . 18 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 This draft is an exploration of the requirements, the alternatives, 110 and trade-offs in BGP peer auto-discovery at various layers in the 111 stack. It is based on discussions in the IDR Working Group BGP 112 Autoconf Design Team. The current target environment is the 113 datacenter. 115 2. Design Team Determinations 117 2.1. Problem Scope 119 The current target environment is BGP as used for the underlay 120 routing protocol in data center networks. Other scenarios may be 121 considered as part of the analysis for this work, but work on those 122 environments will be deferred to other efforts. 124 2.2. Simplicity 126 The auto-discovery mechanism is designed to be simple. 128 The goal is to select BGP Speakers where a BGP session may be 129 successfully negotiated for a particular purpose. The auto-discovery 130 mechanism will not replace or conflict with data exchanged by the BGP 131 FSM, including its OPEN message. 133 2.3. BGP Auto-Discovery Protocol State Requirements 135 The Auto-Discovery Protocol is used discover BGP Session end-points. 136 In other words, enough information to for a BGP Speaker to initiate a 137 connection in the BGP protocol. 139 The BGP Session Properties, used by the discovering client to 140 determine acceptability of the discovered session, are "discovered at 141 OPEN" by the client by initiating a BGP session with the discovered 142 end-point. 144 The required state that MUST be carried by the BGP Auto-Discovery 145 Protocol for a discovered session includes: 147 * IP addresses 148 * Transport security parameters 149 * GTSM [RFC5082] configuration, if any 150 * BGP Session Protocol State Version Number 152 BGP Session Protocol State, discovered at BGP OPEN: 154 * AS Numbers 155 * BGP Identifier 156 * Supported AFI/SAFIs 158 2.3.1. BGP Auto-Discovery Protocol State 160 * Support for IPv4 and IPv6 address families, but do not assume that 161 both are available. 162 * The ability to use directly attached interface addresses, or the 163 device's Loopback address. When using the Loopback address, 164 potentially exchange additional information to bootstrap 165 forwarding to that address. 166 * Discovery of BGP transport protocol end-points and essential 167 properties such as IP addresses, transport security parameters, 168 and support for GTSM. 169 * Transport security parameters include protocol - such as plain 170 TCP, TCP-AO [RFC5925], IPsec [RFC4301], TCP-MD5 [RFC2385] - and 171 necessary configuration for that protocol. Some example 172 considerations for this are represented in YANG Data Model for Key 173 Chains [RFC8177]. 174 * A version number representing when the BGP Session Protocol State 175 has last changed. This can be used as a hint by an auto-discovery 176 client to determine when the state has been updated from a prior 177 version. This can reduce repeated connections from an auto- 178 discovery client to the discovered BGP Speaker when information 179 has not changed. 181 2.3.2. BGP Session Protocol State 183 * Discovery of BGP peer session parameters relevant to peer 184 selection such as Autonomous System (AS) Numbers, BGP Identifiers, 185 supported address families/subsequent-address families (AFI/ 186 SAFIs). 188 2.4. BGP Auto-Discovery Protocol Transport Requirements 190 BGP Auto-Discovery Protocol State may be carried in multiple 191 protocols operating in different transport layers. 193 Implementations supporting more than one protocol for this state must 194 have a mechanism for consistently selecting discovered BGP sessions. 195 The BGP Identifier, which is carried by the BGP OPEN message, can 196 help detect sessions to the same BGP Speaker carried in multiple 197 protocols. 199 2.5. Operator Configuration 201 With BGP auto-discovery, some configuration of BGP is still needed. 202 Operator configuration should be able to decide at least the 203 following: 205 * Select or otherwise filter which peers to actually try to send BGP 206 OPEN messages. 207 * Decide the parameters to use. For example: 208 - IP addressing: IPv4 or IPv6. 209 - Interface for peering: Loopback, or Direct. 210 - Any special forwarding or routing needed for reaching the 211 prospective peer; for example, loopback. 212 - AS numbering. 213 - BGP Transport Security Parameters. 214 - BGP Policy that is appropriate for the type of discovered 215 session. 217 In addition to actually forming the BGP sessions, a common deployment 218 model may also be the so called "validation" model. In this model, 219 the operator configures the BGP sessions manually, and uses the 220 information collected/populated by the BGP Auto-Configuration 221 mechanism to validate that the sessions are correct. 223 3. Design Principle Considerations 225 This section summarizes the considerations of possible criteria for 226 the design of a BGP auto-discovery mechanism, which may need further 227 discussion in a wider community than the design team; for example, 228 the IDR Working Group. 230 3.1. Transport Considerations 232 The network layer of the discovery mechanism may impact the scoping 233 of the deployment of the auto-discovery mechanism. 235 * Layer 2: For example, based on Ethernet. 236 * Layer 3: Which is generic for any link-layer protocol. 238 Potentially leveraging existing protocols deployed in the data 239 center. 241 The length of messages supported by the protocol. 243 How extensible the protocol is to carry future state for BGP auto- 244 configuration. 246 3.2. Auto-Discovery Protocol Timing Considerations 248 Establishing a reasonable expectation for the timeliness of auto- 249 configuration is desirable. When a link is plugged-in, one shouldn't 250 have to wait minutes for potential peers to be discovered and BGP 251 session establishment attempted. For protocols crafted explicitly 252 for BGP auto-configuration, the time for discovery should be a 253 reasonable amount of time; for example ten seconds or less. 255 Since discovery mechanisms may become very chatty when utilized by a 256 number of devices on shared networks, the protocol should not impose 257 undue burden on the devices on that network to process the discovery 258 messages. New auto-discovery protocols MUST NOT transmit messages 259 more than once a second. 261 When an auto-discovery mechanism is used for a point-to-point link, 262 or with the expectation of establishing a BGP session with a single 263 BGP Speaker on that network, the auto-discovery protocol MAY quiesce 264 once the discovered BGP session has become Established. 266 In cases where the auto-discovery protocol is carried as state in 267 another protocol, that protocol will have its own timeliness 268 considerations. The auto-discovery mechanism SHOULD NOT interfere 269 with the timing of the existing protocol. 271 3.3. Relationship with BGP 273 * The auto-discovery mechanism should be independent from BGP 274 session establishment. 275 * Not affect on BGP session establishment and routing exchange, 276 other than the interactions for triggering the setup/removal of 277 peer sessions based on the discovery mechanism. 278 * Potentially leveraging existing BGP protocol sessions for 279 discovery of new BGP sessions. 281 3.4. Session Selection Considerations 283 Candidate BGP sessions to a given BGP Speaker may be discovered by 284 one or more auto-discovery protocols. Even for a single protocol, 285 multiple transport session endpoints may be discovered for the same 286 BGP Speaker. These different sessions may be required for supporting 287 different address families, such as IPv4/IPv6, depending on the BGP 288 operational practices for that device. Examples include a distinct 289 and matching session for the IPv4/IPv6 address family, a unified 290 session carrying IPv4 over IPv6 and vice-versa, etc. 292 The BGP Identifier (router-id), a required protocol component of BGP, 293 can serve to identify the same instance of the BGP Speaker. This is 294 a required element of the information to be carried in the auto- 295 discovery protocol. 297 When multiple mechanisms exist to discovery the same BGP speaker in 298 an implementation, that implementation MUST document the process by 299 which it chooses discovered peers. Those implementations also MUST 300 describe interactions with their protocol state machinery for each 301 mechanism. 303 3.5. Session Stability Considerations 305 BFD [RFC5880] is often used to provide fast failure detection for the 306 BGP protocol. To provide for maximum compatibility and ease of use 307 for auto-discovered sessions, [I-D.ietf-idr-bgp-bfd-strict-mode] 308 SHOULD be used to provide consistent BFD protection for an auto- 309 discovered BGP session. 311 3.6. Operational Trust Considerations 313 Different deployment models will have different trust models and 314 requirements. Some of this will be driven by the size, complexity 315 and operational practices of the operator. For example, some 316 operators have very strict physical protection of the datacenter, and 317 their deployment model assumes that anything which plugs into devices 318 in the datacenter is, by definition, trusted. Other operators take a 319 very different approach, and assume the least possible amount of 320 trust. 322 Much of this difference is also reflected in the operator's 323 bootstrapping solution. Some operators build individual 324 configurations for each device, and manually provision the 325 configuration into the non-volatile storage of the device before it 326 is shipped. Other operators use solutions similar to PXE Boot to 327 automatically load an operating system and configuration onto the 328 device, based on a unique device identifier (such as management 329 Ethernet MAC address). Some operators pre-configure devices with 330 identical base configurations containing some bootstrapping policy 331 logic (e.g., "If you are a Model-X device, and interface 23 is 332 connected to a device of type Y, then you must be at Stage-2 in a 333 Clos fabric") and allow the device to use this policy information to 334 infer its role and position. A final set of datacenter operators, 335 for example enterprises, would like to be able to simply unpack a new 336 device, plug it in and have the device infer everything. (It is 337 unclear if this is a deployment model that we want to support.) 339 Many datacenter operators already have a well-developed process for 340 installing and bringing up a new datacenter network, complete with 341 solutions to bootstrap and configure the network. These operators 342 will want to be able to use the BGP Autoconf mechanism to perform 343 validation of the datacenter fabric, and ongoing "sanity-checking" to 344 confirm that the datacenter is correctly cabled, and that the BGP 345 sessions which have been configured from the database match what the 346 autodiscovered sessions would have created. Over time, if the BGP 347 Autoconf solution proves to be successful, reliable, and scaleable, 348 operators may begin using it as the primary source of record. 350 Closely related to these considerations is the "scope" of the 351 discovery process. It is expected that many operators will wish to 352 only perform discovery on "infrastructure" or "fabric" interfaces, 353 and not interfaces to customers. 355 It is not clear that the solution that chosen will be able to meet 356 all of the trust and deployment models, and we will need to 357 prioritize which set(s) of deployment scenarios are the most 358 important for the Working Group to solve. 360 Trust/Operational deployment driven requirements. The solution 361 should: 363 * Allow operators to determine which classes of interfaces the 364 discovery protocol operates on (e.g: "Interfaces numbered 1-17" or 365 "Only 100GE interfaces"). This is likely an implementation 366 detail. 367 * Allow operation in a "validation" or "verification" only mode, 368 where the Autoconf solution populates a database or model showing 369 what sessions it would bring up if allowed. 371 * Ideally allow for different levels of "granularity" in pre- 372 configuration. For example, if the protocol is capable of 373 autoconfiguring everything, it should also support filtering or 374 limiting the session according to configured policy. (Likely an 375 implementation detail.) 376 * Support preconfigured authentication systems. This is an area 377 where more discussion is needed! The solution MUST also support a 378 "no authentication" mode. Negotiated keying solutions, such as 379 IKE, may be desireable but not mandatory for the solution. 380 * Support Ethernet sub-interfaces such as VLANs. 381 * Support non-Ethernet interfaces. This may include tunnels. 383 3.7. Error Handling Considerations 385 The purpose of the BGP auto-discovery protocol is to discover 386 potential BGP sessions and provide enough information for a BGP 387 Speaker to start a BGP session. It is possible for the information 388 present in the auto-discovery protocol to not match the session's 389 information. Such mis-matches will result in different classes of 390 problems: 392 * The BGP transport session may not connect. This could be the 393 result of mismatches in IP addresses, GTSM configuration, BGP 394 transport security configuration, etc. In these cases, a BGP 395 Speaker attempts to establish a session and fails. 396 Implementations SHOULD provide a way to clear such discovered 397 sessions or exclude them from further connect attempts. 398 * The BGP transport session connects, but the parameters in the BGP 399 OPEN message do not match those in the auto-discovery protocol. 400 In this case, the implementation may wish to disconnect from the 401 BGP session and exclude it from further connection attempts. The 402 implementation SHOULD raise a visible fault to the operator. The 403 implementation SHOULD provide a mechanism to permit further 404 attempts to connect to the discovered session. 405 * The operator may choose to leverage the auto-discovery mode for 406 validation purposes only. The implementation should provide 407 access to the operator for discovered BGP sessions from the auto- 408 discovery protocol; for example via the user-interface. The 409 implementation SHOULD permit a manually configured BGP session to 410 conflict with information present in the auto-discovery protocol, 411 but SHOULD raise an alarm with the operator that this has been 412 done. 414 4. IANA Considerations 416 This document makes no request of IANA. 418 Note to RFC Editor: this section may be removed on publication as an 419 RFC. 421 5. Security Considerations 423 There are two primary components to be secured in environments 424 utilizing BGP auto-discovery: The BGP transport layer discovered via 425 the protocol, and the auto-discovery protocol itself. 427 5.1. BGP Transport Security Considerations 429 The purpose of the auto-discovery protocol is to ease the setup of 430 BGP sessions for various applications, including data-center fabrics. 431 However, care must be taken to not permit sessions to be setup 432 outside of trusted environments. It is RECOMMENDED that sessions 433 advertised using BGP auto-discovery be protected at the transport 434 layer using mechanisms such as TCP-AO, IPsec, or the deprecated TCP- 435 MD5. 437 It is thus a requirement that the auto-discovery protocol carry 438 sufficient information to determine what transport security is to be 439 used when establishing a BGP session. 441 All Security Considerations from [RFC4272], BGP Security 442 Vulnerabilities Analysis, continue to apply. 444 5.2. Auto-discovery Protocol Considerations 446 As noted in previous sections, BGP auto-discovery be scoped to 447 different portions of the network dependent on the network layar at 448 which it is deployed. The information present in the auto-discovery 449 protocol is considered sensitive, since it identifies resources 450 running the BGP protocol. Care should be exercised in avoiding 451 inadvertent disclosure of BGP sessions that are configured to permit 452 auto-configuration even when BGP session transport security is in 453 use. The auto-discovery protocol sets the context for such 454 inadvertent disclosure. 456 5.2.1. Potential Scopes of an Auto-discovery Protocol 458 A Layer 2 unicast protocol targets a known device, potentially 459 discovered through other means. The targeted device receives the 460 message. Depending on the Layer 2 environment, other devices on the 461 same link may may be able to observe the protocol messages. Point to 462 point links may also fall into this category. 464 A Layer 2 multicast protocol targets a group of devices on that Layer 465 2 multicast domain. A set of devices in that domain receives the 466 message. Such messages may cross a number of devices in the domain. 467 An example of this includes a set of Ethernet switches. 469 A Layer 3 unicast protocol inherits the properties of the Layer 2 470 protocol, and is intended to address a specific address - typically 471 one device. Layer 3 unicast protocols may leverage GTSM for their 472 security. 474 A Layer 3 multicast protocol addresses a group of devices in a given 475 multicast domain. Such domains may be scoped, such as a single 476 link's "All-Routers" group or perhaps all devices subscribed to a 477 specific multicast group in a network. In many cases, a Layer 3 478 multicast protocol inherits the properties of the Layer 2 multicast 479 protocol. Link-local scoped multicast protocols may be able to 480 leverage GTSM. 482 A Layer 7 protocol is scoped per the mechanism in the underlying 483 protocol. IGPs such as OSPF and IS-IS provide an "internal" scoping. 484 BGP, depending on the deployment of the underlying address family, 485 may vary from a targeted advertisement, to Internet-wide. 487 Each of these scopes provide different opportunities for inadvertent 488 disclosure. The auto-discovery protocol will need to address how the 489 desired security properties interact with the protocol scope. 491 5.2.2. Desired Security Properties of the Auto-discovery Protocols 493 Data Integrity is a required property. The data that is transmitted 494 by a speaker of the auto-configuration protocol should be able to 495 pass among its speakers properly. 497 Peer Entity authentication is a required property for Layer 2 and 498 Layer 3 implementations. In a Layer 7 protocol, that protocol may 499 provide the necessary authentication. 501 Confidentiality is an optional property. There is a tension between 502 the desire to provide for a simple auto-configuration protocol that 503 is easy to diagnose and debug with inadvertent disclosure. 505 The auto-configuration protocol must be resistant to Denial of 506 Service, and to causing Denial of Service to discovered BGP session 507 end-points. 509 6. Acknowledgments 511 The IDR BGP Auto-Conf Design Team. 513 7. References 515 7.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 524 May 2017, . 526 7.2. Informative References 528 [I-D.acee-idr-lldp-peer-discovery] 529 Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, 530 "BGP Logical Link Discovery Protocol (LLDP) Peer 531 Discovery", Work in Progress, Internet-Draft, draft-acee- 532 idr-lldp-peer-discovery-10, 8 August 2021, 533 . 536 [I-D.acee-ospf-bgp-rr] 537 Lindem, A., Patel, K., Zandi, S., and R. Raszuk, "OSPF 538 Extensions for Advertising/Signaling BGP Route Reflector 539 Information", Work in Progress, Internet-Draft, draft- 540 acee-ospf-bgp-rr-01, 7 September 2017, 541 . 544 [I-D.ietf-idr-bgp-bfd-strict-mode] 545 Zheng, M., Lindem, A., Haas, J., and A. Fu, "BGP BFD 546 Strict-Mode", Work in Progress, Internet-Draft, draft- 547 ietf-idr-bgp-bfd-strict-mode-06, 8 November 2021, 548 . 551 [I-D.ietf-lsvr-l3dl] 552 Bush, R., Austein, R., and K. Patel, "Layer-3 Discovery 553 and Liveness", Work in Progress, Internet-Draft, draft- 554 ietf-lsvr-l3dl-08, 14 October 2021, 555 . 558 [I-D.ietf-lsvr-l3dl-signing] 559 Bush, R., Housley, R., and R. Austein, "Layer-3 Discovery 560 and Liveness Signing", Work in Progress, Internet-Draft, 561 draft-ietf-lsvr-l3dl-signing-03, 14 October 2021, 562 . 565 [I-D.ietf-lsvr-l3dl-ulpc] 566 Bush, R. and K. Patel, "L3DL Upper-Layer Protocol 567 Configuration", Work in Progress, Internet-Draft, draft- 568 ietf-lsvr-l3dl-ulpc-02, 14 October 2021, 569 . 572 [I-D.ietf-lsvr-lsoe] 573 Bush, R., Austein, R., and K. Patel, "Link State Over 574 Ethernet", Work in Progress, Internet-Draft, draft-ietf- 575 lsvr-lsoe-01, 17 February 2019, 576 . 579 [I-D.raszuk-idr-bgp-auto-discovery] 580 Raszuk, R., Mitchell, J., Kumari, W., Patel, K., and J. 581 Scudder, "BGP Auto Discovery", Work in Progress, Internet- 582 Draft, draft-raszuk-idr-bgp-auto-discovery-07, 13 October 583 2021, . 586 [I-D.raszuk-idr-bgp-auto-session-setup] 587 Raszuk, R., "BGP Automated Session Setup", Work in 588 Progress, Internet-Draft, draft-raszuk-idr-bgp-auto- 589 session-setup-01, 11 December 2019, 590 . 593 [I-D.xu-idr-neighbor-autodiscovery] 594 Xu, X., Talaulikar, K., Bi, K., Tantsura, J., and N. 595 Triantafillis, "BGP Neighbor Discovery", Work in Progress, 596 Internet-Draft, draft-xu-idr-neighbor-autodiscovery-12, 26 597 November 2019, . 600 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 601 Converting Network Protocol Addresses to 48.bit Ethernet 602 Address for Transmission on Ethernet Hardware", STD 37, 603 RFC 826, DOI 10.17487/RFC0826, November 1982, 604 . 606 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 607 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 608 1998, . 610 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 611 RFC 4272, DOI 10.17487/RFC4272, January 2006, 612 . 614 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 615 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 616 December 2005, . 618 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 619 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 620 DOI 10.17487/RFC4861, September 2007, 621 . 623 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 624 Pignataro, "The Generalized TTL Security Mechanism 625 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 626 . 628 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 629 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 630 . 632 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 633 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 634 June 2010, . 636 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 637 Zhang, "YANG Data Model for Key Chains", RFC 8177, 638 DOI 10.17487/RFC8177, June 2017, 639 . 641 Appendix A. Analysis of Candidate Approaches 643 As part of the work on distilling the requirements for BGP auto- 644 discovery, the Design Team reviewed several proposals for 645 implementing auto-discovery. The analysis of these proposals, 646 including missing elements the Design Team decided were part of the 647 requirements, follows. 649 A.1. BGP Peer Discovery at Layer Two 651 BGP Discovery at Layer-2 would entail finding potential peers on a 652 LAN or on Point-to-Point links and discovering their Layer-3 653 attributes, such as, IP addresses, etc. 655 There are two available candidates for peer discovery at Layer-2, one 656 is based on Link Layer Discovery Protocol (LLDP) and the other is 657 based on Layer 3 Discovery Protocol, L3DL [I-D.ietf-lsvr-l3dl]. 659 A.1.1. LLDP based Approach 661 LLDP is a widely deployed protocol with implementations in most 662 devices in data centers. Currently it only advertises the managment 663 Layer-3 address, but could presumably be extended to include the per- 664 interface addresses. 666 LLDP has a limitation that all information must fit in a single PDU 667 (it does not support fragmentation / a "session"). There is an early 668 LLDPv2 development effort to extend this in the IEEE. 670 [I-D.acee-idr-lldp-peer-discovery] describes how to use the LLDP IETF 671 Organizationally Specific TLV to augment the LLDP TLV set to exchange 672 BGP Config Sub-TLVs signaling: 674 * AFI 675 * IP address (IPv4 or IPv6) 676 * Local AS number 677 * Local BGP Identifier (AKA, BGP Router ID) 678 * Session Group-ID; i.e., the BGP Device Role 679 * BGP Session Capabilities 680 * Key Chain 681 * Local Address (as BGP Next Hop). 683 A.1.2. L3DL based Approach 685 L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR 686 Working Group with the goal of discovering IP Layer-3 attributes of 687 links, such as neighbor IP addressing, logical link IP encapsulation 688 abilities, and link liveness which may then be disseminated for the 689 use of BGP-SPF and similar protocols. 691 L3DL Upper Layer Protocol Configuration, [I-D.ietf-lsvr-l3dl-ulpc], 692 details signaling the minimal set of parameters needed to start a BGP 693 session with a discovered peer. Details such as loopback peering are 694 handled by attributes in the L3DL protocol itself. The information 695 which can be discovered by L3DL is: 697 * AS number 698 * Local IP address, IPv4 or IPv6, and 699 * BGP Authentication. 701 L3DL and L3DL-ULPC have well-specified security mechanisms, see 702 [I-D.ietf-lsvr-l3dl-signing]. 704 The functionality of L3DL-ULPC is similar but not quite the same as 705 the needs of IDR Design Team. For example, L3DL is designed to meet 706 more complex needs. L3DL's predecessor, LSOE [I-D.ietf-lsvr-lsoe], 707 was simpler and might be a better candidate for adaptation. If 708 needed, the design of LSOE may be customized for the needs of BGP 709 peer auto- disovery. 711 Unlike LLDP, L3DL has only one implementation, and LSOE has only one 712 open source implementation, and neither is significantly deployed. 714 A.2. Link-Local Discovery 716 Some existing BGP auto-configuration mechanisms leverage "point to 717 point" addressing schemes to bootstrap BGP sessions. One example 718 utilizes an IP subnet numbered such that it may contain only two 719 hosts - for IPv4, a /30 or /31 network; for IPv6 a /127 network. An 720 additional mechanism may leverage IPv4 ARP [RFC0826] or IPv6 Neighbor 721 Discovery [RFC4861] to learn of hosts on a subnet. 723 Such existing mechanisms do not provide an auto-discovery protocol 724 with necessary parameters. Rather, they simplify configuration by 725 permitting BGP session configuration templates to be easily applied 726 to interfaces without requiring addressing to be known a priori. 728 A.3. BGP peer Discovery at Layer Three 730 Discovery at Layer-3 can assume IP addressability, though the IP 731 addresses of potential peers are not known a priori and need to be 732 discovered before further negotiation. IP multicast may be a good 733 choice to address the above concern. 735 The possible problem would appear to discovery at Layer-3 is that one 736 may not know whether to use IPv4 or IPv6. This might be exacerbated 737 by the possibility of a potential peer not being on the local subnet, 738 and hence broadcast and similar techniques may not be applicable. 739 While in data center network or networks in a single administrative 740 domain, such issue could be easily solved. 742 If one can assume that the BGP session is based on point-to-point 743 link, then discovery might try IPv6 link-local or even IPv4 link- 744 local. A link broadcast or multicast protocol may also be used. For 745 switched or bridged multi-point which is at least on the same subnet, 746 VLAN, etc., multicast or broadcasts might be a viable approach. 748 There are four available candidates for BGP peer discovery at Layer- 749 3: One is based on extending BGP with new Hello message for peer 750 auto-discovery. One is based on reusing BGP OPEN message format for 751 peer auto-discovery. One is based on bootstrapping BGP sessions via 752 existing BGP sessions. One is based upon bootstraping a BGP Route 753 Reflector via the OSPF protocol. 755 A.3.1. New BGP Hello Message based Approach 757 [I-D.xu-idr-neighbor-autodiscovery] describes a BGP neighbor 758 discovery mechanism which is based on a newly defined UDP based BGP 759 Hello message. The BGP Hello message is sent in multicast to 760 discover the directly connected BGP peers. According to the message 761 header format and the TLVs carried in the message, the information 762 which can be signaled is: 764 * AS number 765 * BGP Identifier 766 * Accepted ASN list 767 * Peering address (IPv4 or IPv6) 768 * Local prefix (for loopback) 769 * Link attributes 770 * Neighbor state 771 * BGP Authentication 773 The mechanisms in this draft do not currently handle fragmentation. 775 The mechanism in this draft is perhaps unique among the other 776 proposals in requiring bi-directional state. 778 A.3.2. BGP OPEN Message based Approach 780 [I-D.raszuk-idr-bgp-auto-session-setup] describes a BGP neighbor 781 discovery mechanism by reusing BGP OPEN message format with newly 782 defined UDP port. The message is called BGP Session Explorer (BSE) 783 packet and is sent in multicast. Since the message format is the 784 same as BGP OPEN, the information which can be signaled is: 786 * AS number 787 * BGP Identifier 788 * Peering address 790 The mechanism is currently under-specified with respect to a number 791 of similar properties described elsewhere. A general implication is 792 that those properties - and others providing for extensibility of the 793 auto-discovery mechanism - would need to be added to the BGP OPEN 794 message and deal with the related impacts on the BGP session's 795 finite-state machine. 797 BGP PDUs, including the OPEN message, may be up to 4k in size. Since 798 this mechanism leverages Layer 3 multicast, a PDU fragmentation 799 mechanism may need to be described. 801 A.3.3. Bootstrapping BGP via BGP 803 [I-D.raszuk-idr-bgp-auto-discovery] describes a new BGP address 804 family. The NLRI carries a Group ID + BGP Identifier as the key. A 805 new BGP Path Attribute carries information about the sessions: 807 * AS Number 808 * AFI/SAFI 809 * BGP Identifier 810 * Peer Transport Address 811 * Flags to declare a session for information only, to force a reset 812 of a session on parameter changes, etc. 814 Since the BGP auto-discovery state is carried by BGP, it inherits the 815 security implications of the underlying BGP session. 817 PDU size considerations are identical to those of a BGP UPDATE 818 message. 820 Similarly, extensibility considerations would rely on either the new 821 BGP Path Attribute, or one yet to be defined. 823 A.3.4. Bootstrapping BGP via OSPF 825 [I-D.acee-ospf-bgp-rr] describes a mechanism to learn BGP Route 826 Reflectors via OSPFv2/OSPFv3 LSAs. Multiple types of scopes are 827 defined for these LSAs to help constrain where they are advertised in 828 an OSPF domain. 830 The BGP Route Reflector TLV contains: 832 * Local AS Number 833 * IPv4 or IPv6 Address of the Route Reflector 834 * A list of AFI/SAFIs supported by the Route Reflector 836 The BGP Route Reflector TLV may be advertised more than once, 837 potentially to describe different IP transport endpoints. 839 This mechanism does not provide for security properties of the BGP 840 session or transport properties such as BFD or GTSM. 842 Authors' Addresses 843 Randy Bush 844 Arrcus, Inc. & Internet Initiative Japan 845 5147 Crystal Springs 846 Bainbridge Island, WA 98110 847 United States of America 849 Email: randy@psg.com 851 Jie Dong 852 Huawei Technologies 853 Huawei Campus, No. 156 Beiqing Road 854 Beijing 855 100095 856 China 858 Email: jie.dong@huawei.com 860 Jeffrey Haas (editor) 861 Juniper Networks 862 1133 Innovation Way 863 Sunnyvale, CA 94089 864 United States of America 866 Email: jhaas@juniper.net 868 Warren Kumari (editor) 869 Google 870 1600 Amphitheatre Parkway 871 Mountain View, CA 94043 872 United States of America 874 Email: warren@kumari.net