idnits 2.17.1 draft-ietf-idr-bgp-autoconf-considerations-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 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 (March 8, 2021) is 1144 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-08 == Outdated reference: A later version (-12) exists of draft-ietf-lsvr-l3dl-07 == Outdated reference: A later version (-06) exists of draft-ietf-lsvr-l3dl-signing-01 == Outdated reference: A later version (-05) exists of draft-ietf-lsvr-l3dl-ulpc-01 == Outdated reference: A later version (-08) exists of draft-raszuk-idr-bgp-auto-discovery-06 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 0 errors (**), 0 flaws (~~), 7 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: September 9, 2021 Huawei Technologies 6 J. Haas, Ed. 7 Juniper Networks 8 W. Kumari, Ed. 9 Google 10 March 8, 2021 12 Requirements and Considerations in BGP Peer Auto-Configuration 13 draft-ietf-idr-bgp-autoconf-considerations-00 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 September 9, 2021. 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Design Team Determinations . . . . . . . . . . . . . . . . . 3 69 2.1. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 3 71 2.3. BGP Auto-Discovery Protocol State Requirements . . . . . 3 72 2.3.1. BGP Session Transport State . . . . . . . . . . . . . 4 73 2.3.2. BGP Session Protocol State . . . . . . . . . . . . . 4 74 2.4. BGP Auto-Discovery Protocol Transport Requirements . . . 5 75 2.5. Operator Configuration . . . . . . . . . . . . . . . . . 5 76 3. Design Principle Considerations . . . . . . . . . . . . . . . 6 77 3.1. Transport Considerations . . . . . . . . . . . . . . . . 6 78 3.2. Auto-Discovery Protocol Timing Considerations . . . . . . 6 79 3.3. Relationship with BGP . . . . . . . . . . . . . . . . . . 7 80 3.4. Session Selection Considerations . . . . . . . . . . . . 7 81 3.5. Operational Trust Considerations . . . . . . . . . . . . 7 82 3.6. 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 . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 14 97 A.1.2. L3DL based Approach . . . . . . . . . . . . . . . . . 15 99 A.2. Link-Local Discovery . . . . . . . . . . . . . . . . . . 15 100 A.3. BGP peer Discovery at Layer Three . . . . . . . . . . . . 16 101 A.3.1. New BGP Hello Message based Approach . . . . . . . . 16 102 A.3.2. BGP OPEN Message based Approach . . . . . . . . . . . 17 103 A.3.3. Bootstrapping BGP via BGP . . . . . . . . . . . . . . 17 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 Tersely, the required state that MUST be carried by the BGP Auto- 136 Discovery Protocol for a discovered session include: 138 BGP Session Transport State: 140 o IP addresses 141 o Transport security parameters 142 o GTSM [RFC5082] configuration, if any 143 o BFD [RFC5880] configuration, if any 145 BGP Session Protocol State: 147 o AS Numbers 148 o BGP Identifier 149 o Supported AFI/SAFIs 150 o Device Role 152 Once this information has been learned, discovery has been completed. 153 The BGP Speaker has the necessary information to determine if it 154 wishes to open a BGP session with the discovered BGP Speaker. It can 155 then then initiate a BGP session with the discovered BGP Speaker. 157 2.3.1. BGP Session Transport State 159 o Support for IPv4 and IPv6 address families, but do not assume that 160 both are available. 161 o The ability to use directly attached interface addresses, or the 162 device's Loopback address. When using the Loopback address, 163 potentially exchange additional information to bootstrap 164 forwarding to that address. 165 o Discovery of BGP transport protocol end-points and essential 166 properties such as IP addresses, transport security parameters, 167 layer 3 liveness mechanisms such as BFD, and support for GTSM. 168 o Transport security parameters include protocol - such as plain 169 TCP, TCP-AO [RFC5925], IPsec [RFC4301], TCP-MD5 [RFC2385] - and 170 necessary configuration for that protocol. Some example 171 considerations for this are represented in YANG Data Model for Key 172 Chains [RFC8177]. 174 2.3.2. BGP Session Protocol State 176 o Discovery of BGP peer session parameters relevant to peer 177 selection such as Autonomous System (AS) Numbers, BGP Identifiers, 178 supported address families/subsequent-address families (AFI/ 179 SAFIs), and device roles. 181 2.3.2.1. BGP Auto-Discovery Device Role Requirements 183 As part of peer selection, it may be necessary to understand the role 184 of the discovered session to determine whether or not the BGP Speaker 185 desires to establish a peering session. 187 In some cases, role may be a clear function of the device in a 188 deployment. An example of this is a discovered session for a BGP 189 Clos fabric: The interface may for a leaf, the aggregation layer, or 190 the spine layer. Even then, the type of fabric, what pod it belongs 191 to and the peer type may be relevant information. 193 Some types of device roles may be subject to standardization, such as 194 BGP Clos fabrics. Flexibility to permit operators to use device 195 roles for their own auto-configuration peer selection purposes is a 196 requirement. 198 Peering sessions may need to advertise that they are capable to be 199 used for multiple roles. Thus, it is a requirement that the auto- 200 discovery protocols permit advertising multiple roles in the same 201 PDU. 203 2.4. BGP Auto-Discovery Protocol Transport Requirements 205 BGP Auto-Discovery Protocol State may be carried in multiple 206 protocols operating in different transport layers. 208 Implementations supporting more than one protocol for this state must 209 have a mechanism for consistently selecting discovered BGP sessions. 210 The BGP Identifier, which is carried by the BGP OPEN message, can 211 help detect sessions to the same BGP Speaker carried in multiple 212 protocols. 214 2.5. Operator Configuration 216 With BGP auto-discovery, some configuration of BGP is still needed. 217 Operator configuration should be able to decide at least the 218 following: 220 o Select or otherwise filter which peers to actually try to send BGP 221 OPEN messages. 223 * Permit the matching of device role from the discovery protocol 224 as part of peer selection. 225 o Decide the parameters to use. For example: 227 * IP addressing: IPv4 or IPv6. 228 * Interface for peering: Loopback, or Direct. 229 * Any special forwarding or routing needed for reaching the 230 prospective peer; for example, loopback. 231 * AS numbering. 232 * BGP Transport Security Parameters. 233 * BGP Policy that is appropriate for the type of discovered 234 session. 236 In addition to actually forming the BGP sessions, a common deployment 237 model may also be the so called "validation" model. In this model, 238 the operator configures the BGP sessions manually, and uses the 239 information collected/populated by the BGP Autoconf mechanism to 240 validate that the sessions are correct. 242 3. Design Principle Considerations 244 This section summarizes the considerations of possible criteria for 245 the design of a BGP auto-discovery mechanism, which may need further 246 discussion in a wider community than the design team; for example, 247 the IDR Working Group. 249 3.1. Transport Considerations 251 The network layer of the discovery mechanism may impact the scoping 252 of the deployment of the auto-discovery mechanism. 254 o Layer 2: For example, based on Ethernet. 255 o Layer 3: Which is generic for any link-layer protocol. 257 Potentially leveraging existing protocols deployed in the data 258 center. 260 The length of messages supported by the protocol. 262 How extensible the protocol is to carry future state for BGP auto- 263 configuration. 265 3.2. Auto-Discovery Protocol Timing Considerations 267 Establishing a reasonable expectation for the timeliness of auto- 268 configuration is desirable. When a link is plugged-in, one shouldn't 269 have to wait minutes for potential peers to be discovered and BGP 270 session establishment attempted. For protocols crafted explicitly 271 for BGP auto-configuration, the time for discovery should be a 272 reasonable amount of time; for example ten seconds or less. 274 Since discovery mechanisms may become very chatty when utilized by a 275 number of devices on shared networks, the protocol should not impose 276 undue burden on the devices on that network to process the discovery 277 messages. New auto-discovery protcols MUST NOT transmit messages 278 more than once a second. 280 When an auto-discovery mechanism is used for a point-to-point link, 281 or with the expectation of establishing a BGP session with a single 282 BGP Speaker on that network, the auto-discovery protocol MAY quiesce 283 once the discovered BGP session has become Established. 285 In cases where the auto-discovery protocol is carried as state in 286 another protocol, that protocol will have its own timeliness 287 considerations. The auto-discovery mechanism SHOULD NOT interfere 288 with the timing of the existing protocol. 290 3.3. Relationship with BGP 292 o The auto-discovery mechanism should be independent from BGP 293 session establishment. 294 o Not affect on BGP session establishment and routing exchange, 295 other than the interactions for triggering the setup/removal of 296 peer sessions based on the discovery mechanism. 297 o Potentially leveraging existing BGP protocol sessions for 298 discovery of new BGP sessions. 300 3.4. Session Selection Considerations 302 Candidate BGP sessions to a given BGP Speaker may be discovered by 303 one or more auto-discovery protocols. Even for a single protocol, 304 multiple transport session endpoints may be discovered for the same 305 BGP Speaker. These different sessions may be required for supporting 306 different address families, such as IPv4/IPv6, depending on the BGP 307 operational practices for that device. Examples include a distinct 308 and matching session for the IPv4/IPv6 address family, a unified 309 session carrying IPv4 over IPv6 and vice-versa, etc. 311 The BGP Identifier (router-id), a required protocol component of BGP, 312 can serve to identify the same instance of the BGP Speaker. This is 313 a required element of the information to be carried in the auto- 314 discovery protocol. 316 When multiple mechanisms exist to discovery the same BGP speaker in 317 an implementation, that implementation MUST document the process by 318 which it chooses discovered peers. Those implementations also MUST 319 describe interactions with their protocol state machinery for each 320 mechanism. 322 3.5. Operational Trust Considerations 324 Different deployment models will have different trust models and 325 requirements. Some of this will be driven by the size, complexity 326 and operational practices of the operator. For example, some 327 operators have very strict physical protection of the datacenter, and 328 their deployment model assumes that anything which plugs into devices 329 in the datacenter is, by definition, trusted. Other operators take a 330 very different approach, and assume the least possible amount of 331 trust. 333 Much of this difference is also reflected in the operator's 334 bootstrapping solution. Some operators build individual 335 configurations for each device, and manually provision the 336 configuration into the non-volatile storage of the device before it 337 is shipped. Other operators use solutions similar to PXE Boot to 338 automatically load an operating system and configuration onto the 339 device, based on a unique device identifier (such as management 340 Ethernet MAC address). Some operators pre-configure devices with 341 identical base configurations containing some bootstrapping policy 342 logic (e.g., "If you are a Model-X device, and interface 23 is 343 connected to a device of type Y, then you must be at Stage-2 in a 344 Clos fabric") and allow the device to use this policy information to 345 infer its role and position. A final set of datacenter operators, 346 for example enterprises, would like to be able to simply unpack a new 347 device, plug it in and have the device infer everything. (It is 348 unclear if this is a deployment model that we want to support.) 350 Many datacenter operators already have a well-developed process for 351 installing and bringing up a new datacenter network, complete with 352 solutions to bootstrap and configure the network. These operators 353 will want to be able to use the BGP Autoconf mechanism to perform 354 validation of the datacenter fabric, and ongoing "sanity-checking" to 355 confirm that the datacenter is correctly cabled, and that the BGP 356 sessions which have been configured from the database match what the 357 autodiscovered sessions would have created. Over time, if the BGP 358 Autoconf solution proves to be successful, reliable, and scaleable, 359 operators may begin using it as the primary source of record. 361 Closely related to these considerations is the "scope" of the 362 discovery process. It is expected that many operators will wish to 363 only perform discovery on "infrastructure" or "fabric" interfaces, 364 and not interfaces which face customers. 366 It is not clear that the solution that chosen will be able to meet 367 all of the trust and deployment models, and we will need to 368 prioritize which set(s) of deployment scenarios are the most 369 important for the Working Group to solve. 371 Trust/Operational deployment driven requirements. The solution 372 should: 374 o Allow operators to determine which classes of interfaces the 375 discovery protocol operates on (e.g: "Interfaces numbered 1-17" or 376 "Only 100GE interfaces"). This is likely an implementation 377 detail. 378 o Allow operation in a "validation" or "verification" only mode, 379 where the Autoconf solution populates a database or model showing 380 what sessions it would bring up if allowed. 381 o Ideally allow for different levels of "granularity" in pre- 382 configuration. For example, if the protocol is capable of 383 autoconfiguring everything, it should also support filtering or 384 limiting the session according to configured policy. (Likely an 385 implementation detail.) 387 o Support preconfigured authentication systems. This is an area 388 where more discussion is needed! The solution MUST also support a 389 "no authentication" mode. Negotiated keying solutions, such as 390 IKE, may be desireable but not mandatory for the solution. 391 o Support Ethernet sub-interfaces such as VLANs. 392 o Support non-Ethernet interfaces. This may include tunnels. 394 3.6. Error Handling Considerations 396 The purpose of the BGP auto-discovery protocol is to discover 397 potential BGP sessions and provide enough information for a BGP 398 Speaker to start a BGP session. It is possible for the information 399 present in the auto-discovery protocol to not match the session's 400 information. Such mis-matches will result in different classes of 401 problems: 403 o The BGP transport session may not connect. This could be the 404 result of mismatches in IP addresses, GTSM configuration, BGP 405 transport security configuration, etc. In these cases, a BGP 406 Speaker attempts to establish a session and fails. 407 Implementations SHOULD provide a way to clear such discovered 408 sessions or exclude them from further connect attempts. 409 o The BGP transport session connects, but the parameters in the BGP 410 OPEN message do not match those in the auto-discovery protocol. 411 In this case, the implementation may wish to disconnect from the 412 BGP session and exclude it from further connection attempts. The 413 implementation SHOULD raise a visible fault to the operator. The 414 implementation SHOULD provide a mechanism to permit further 415 attempts to connect to the discovered session. 416 o The operator may choose to leverage the auto-discovery mode for 417 validation purposes only. The implementation should provide 418 access to the operator for discovered BGP sessions from the auto- 419 discovery protocol; for example via the user-interface. The 420 implementation SHOULD permit a manually configured BGP session to 421 conflict with information present in the auto-discovery protocol, 422 but SHOULD raise an alarm with the operator that this has been 423 done. 425 4. IANA Considerations 427 This document makes no request of IANA. 429 Note to RFC Editor: this section may be removed on publication as an 430 RFC. 432 5. Security Considerations 434 There are two primary components to be secured in environments 435 utilizing BGP auto-discovery: The BGP transport layer discovered via 436 the protocol, and the auto-discovery protocol itself. 438 5.1. BGP Transport Security Considerations 440 The purpose of the auto-discovery protocol is to ease the setup of 441 BGP sessions for various applications, including data-center fabrics. 442 However, care must be taken to not permit sessions to be setup 443 outside of trusted environments. It is RECOMMENDED that sessions 444 advertised using BGP auto-discovery be protected at the transport 445 layer using mechanisms such as TCP-AO, IPsec, or the deprecated TCP- 446 MD5. 448 It is thus a requirement that the auto-discovery protocol carry 449 sufficient information to determine what transport security is to be 450 used when establishing a BGP session. 452 All Security Considerations from [RFC4272], BGP Security 453 Vulnerabilities Analysis, continue to apply. 455 5.2. Auto-discovery Protocol Considerations 457 As noted in previous sections, BGP auto-discovery be scoped to 458 different portions of the network dependent on the network layar at 459 which it is deployed. The information present in the auto-discovery 460 protocol is considered sensitive, since it identifies resources 461 running the BGP protocol. Care should be exercised in avoiding 462 inadvertent disclosure of BGP sessions that are configured to permit 463 auto-configuration even when BGP session transport security is in 464 use. The auto-discovery protocol sets the context for such 465 inadvertent disclosure. 467 5.2.1. Potential Scopes of an Auto-discovery Protocol 469 A Layer 2 unicast protocol targets a known device, potentially 470 discovered through other means. The targeted device receives the 471 message. Depending on the Layer 2 environment, other devices on the 472 same link may may be able to observe the protocol messages. Point to 473 point links may also fall into this category. 475 A Layer 2 multicast protocol targets a group of devices on that Layer 476 2 multicast domain. A set of devices in that domain receives the 477 message. Such messages may cross a number of devices in the domain. 478 An example of this includes a set of Ethernet switches. 480 A Layer 3 unicast protocol inherits the properties of the Layer 2 481 protocol, and is intended to address a specific address - typically 482 one device. Layer 3 unicast protocols may leverage GTSM for their 483 security. 485 A Layer 3 multicast protocol addresses a group of devices in a given 486 multicast domain. Such domains may be scoped, such as a single 487 link's "All-Routers" group or perhaps all devices subscribed to a 488 specific multicast group in a network. In many cases, a Layer 3 489 multicast protocol inherits the properties of the Layer 2 multicast 490 protocol. Link-local scoped multicast protocols may be able to 491 leverage GTSM. 493 A Layer 7 protocol is scoped per the mechanism in the underlying 494 protocol. IGPs such as OSPF and IS-IS provide an "internal" scoping. 495 BGP, depending on the deployment of the underlying address family, 496 may vary from a targeted advertisement, to Internet-wide. 498 Each of these scopes provide different opportunities for inadvertent 499 disclosure. The auto-discovery protocol will need to address how the 500 desired security properties interact with the protocol scope. 502 5.2.2. Desired Security Properties of the Auto-discovery Protocols 504 Data Integrity is a required property. The data that is transmitted 505 by a speaker of the auto-configuration protocol should be able to 506 pass among its speakers properly. 508 Peer Entity authentication is a required property for Layer 2 and 509 Layer 3 implementations. In a Layer 7 protocol, that protocol may 510 provide the necessary authentication. 512 Confidentiality is an optional property. There is a tension between 513 the desire to provide for a simple auto-configuration protocol that 514 is easy to diagnose and debug with inadvertent disclosure. 516 The auto-configuration protocol must be resistant to Denial of 517 Service, and to causing Denial of Service to discovered BGP session 518 end-points. 520 6. Acknowledgments 522 The IDR BGP Auto-Conf Design Team. 524 7. References 526 7.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 535 May 2017, . 537 7.2. Informative References 539 [I-D.acee-idr-lldp-peer-discovery] 540 Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, 541 "BGP Logical Link Discovery Protocol (LLDP) Peer 542 Discovery", draft-acee-idr-lldp-peer-discovery-08 (work in 543 progress), December 2020. 545 [I-D.acee-ospf-bgp-rr] 546 Lindem, A., Patel, K., Zandi, S., and R. Raszuk, "OSPF 547 Extensions for Advertising/Signaling BGP Route Reflector 548 Information", draft-acee-ospf-bgp-rr-01 (work in 549 progress), September 2017. 551 [I-D.ietf-lsvr-l3dl] 552 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 553 and Liveness", draft-ietf-lsvr-l3dl-07 (work in progress), 554 January 2021. 556 [I-D.ietf-lsvr-l3dl-signing] 557 Bush, R. and R. Austein, "Layer 3 Discovery and Liveness 558 Signing", draft-ietf-lsvr-l3dl-signing-01 (work in 559 progress), January 2021. 561 [I-D.ietf-lsvr-l3dl-ulpc] 562 Bush, R. and K. Patel, "L3DL Upper Layer Protocol 563 Configuration", draft-ietf-lsvr-l3dl-ulpc-01 (work in 564 progress), January 2021. 566 [I-D.ietf-lsvr-lsoe] 567 Bush, R., Austein, R., and K. Patel, "Link State Over 568 Ethernet", draft-ietf-lsvr-lsoe-01 (work in progress), 569 February 2019. 571 [I-D.raszuk-idr-bgp-auto-discovery] 572 Raszuk, R., Mitchell, J., Kumari, W., Patel, K., and J. 573 Scudder, "BGP Auto Discovery", draft-raszuk-idr-bgp-auto- 574 discovery-06 (work in progress), December 2019. 576 [I-D.raszuk-idr-bgp-auto-session-setup] 577 Raszuk, R., "BGP Automated Session Setup", draft-raszuk- 578 idr-bgp-auto-session-setup-01 (work in progress), December 579 2019. 581 [I-D.xu-idr-neighbor-autodiscovery] 582 Xu, X., Talaulikar, K., Bi, K., Tantsura, J., and N. 583 Triantafillis, "BGP Neighbor Discovery", draft-xu-idr- 584 neighbor-autodiscovery-12 (work in progress), November 585 2019. 587 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 588 Converting Network Protocol Addresses to 48.bit Ethernet 589 Address for Transmission on Ethernet Hardware", STD 37, 590 RFC 826, DOI 10.17487/RFC0826, November 1982, 591 . 593 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 594 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 595 1998, . 597 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 598 RFC 4272, DOI 10.17487/RFC4272, January 2006, 599 . 601 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 602 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 603 December 2005, . 605 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 606 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 607 DOI 10.17487/RFC4861, September 2007, 608 . 610 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 611 Pignataro, "The Generalized TTL Security Mechanism 612 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 613 . 615 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 616 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 617 . 619 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 620 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 621 June 2010, . 623 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 624 Zhang, "YANG Data Model for Key Chains", RFC 8177, 625 DOI 10.17487/RFC8177, June 2017, 626 . 628 Appendix A. Analysis of Candidate Approaches 630 As part of the work on distilling the requirements for BGP auto- 631 discovery, the Design Team reviewed several proposals for 632 implementing auto-discovery. The analysis of these proposals, 633 including missing elements the Design Team decided were part of the 634 requirements, follows. 636 A.1. BGP Peer Discovery at Layer Two 638 BGP Discovery at Layer-2 would entail finding potential peers on a 639 LAN or on Point-to-Point links and discovering their Layer-3 640 attributes, such as, IP addresses, etc. 642 There are two available candidates for peer discovery at Layer-2, one 643 is based on Link Layer Discovery Protocol (LLDP) and the other is 644 based on Layer 3 Discovery Protocol, L3DL [I-D.ietf-lsvr-l3dl]. 646 A.1.1. LLDP based Approach 648 LLDP is a widely deployed protocol with implementations in most 649 devices in data centers. Currently it only advertises the managment 650 Layer-3 address, but could presumably be extended to include the per- 651 interface addresses. 653 LLDP has a limitation that all information must fit in a single PDU 654 (it does not support fragmentation / a "session"). There is an early 655 LLDPv2 development effort to extend this in the IEEE. 657 [I-D.acee-idr-lldp-peer-discovery] describes how to use the LLDP IETF 658 Organizationally Specific TLV to augment the LLDP TLV set to exchange 659 BGP Config Sub-TLVs signaling: 661 o AFI 662 o IP address (IPv4 or IPv6) 663 o Local AS number 664 o Local BGP Identifier (AKA, BGP Router ID) 665 o Session Group-ID; i.e., the BGP Device Role 666 o BGP Session Capabilities 667 o Key Chain 668 o Local Address (as BGP Next Hop). 670 A.1.2. L3DL based Approach 672 L3DL [I-D.ietf-lsvr-l3dl] is an ongoing development in the IETF LSVR 673 Working Group with the goal of discovering IP Layer-3 attributes of 674 links, such as neighbor IP addressing, logical link IP encapsulation 675 abilities, and link liveness which may then be disseminated for the 676 use of BGP-SPF and similar protocols. 678 L3DL Upper Layer Protocol Configuration, [I-D.ietf-lsvr-l3dl-ulpc], 679 details signaling the minimal set of parameters needed to start a BGP 680 session with a discovered peer. Details such as loopback peering are 681 handled by attributes in the L3DL protocol itself. The information 682 which can be discovered by L3DL is: 684 o AS number 685 o Local IP address, IPv4 or IPv6, and 686 o BGP Authentication. 688 L3DL and L3DL-ULPC have well-specified security mechanisms, see 689 [I-D.ietf-lsvr-l3dl-signing]. 691 The functionality of L3DL-ULPC is similar but not quite the same as 692 the needs of IDR Design Team. For example, L3DL is designed to meet 693 more complex needs. L3DL's predecessor, LSOE [I-D.ietf-lsvr-lsoe], 694 was simpler and might be a better candidate for adaptation. If 695 needed, the design of LSOE may be customized for the needs of BGP 696 peer auto- disovery. 698 Unlike LLDP, L3DL has only one implementation, and LSOE has only one 699 open source implementation, and neither is significantly deployed. 701 A.2. Link-Local Discovery 703 Some existing BGP auto-configuration mechanisms leverage "point to 704 point" addressing schemes to bootstrap BGP sessions. One example 705 utilizes an IP subnet numbered such that it may contain only two 706 hosts - for IPv4, a /30 or /31 network; for IPv6 a /127 network. An 707 additional mechanism may leverage IPv4 ARP [RFC0826] or IPv6 Neighbor 708 Discovery [RFC4861] to learn of hosts on a subnet. 710 Such existing mechanisms do not provide an auto-discovery protocol 711 with necessary parameters. Rather, they simplify configuration by 712 permitting BGP session configuration templates to be easily applied 713 to interfaces without requiring addressing to be known a priori. 715 A.3. BGP peer Discovery at Layer Three 717 Discovery at Layer-3 can assume IP addressability, though the IP 718 addresses of potential peers are not known a priori and need to be 719 discovered before further negotiation. IP multicast may be a good 720 choice to address the above concern. 722 The possible problem would appear to discovery at Layer-3 is that one 723 may not know whether to use IPv4 or IPv6. This might be exacerbated 724 by the possibility of a potential peer not being on the local subnet, 725 and hence broadcast and similar techniques may not be applicable. 726 While in data center network or networks in a single administrative 727 domain, such issue could be easily solved. 729 If one can assume that the BGP session is based on point-to-point 730 link, then discovery might try IPv6 link-local or even IPv4 link- 731 local. A link broadcast or multicast protocol may also be used. For 732 switched or bridged multi-point which is at least on the same subnet, 733 VLAN, etc., multicast or broadcasts might be a viable approach. 735 There are four available candidates for BGP peer discovery at Layer- 736 3: One is based on extending BGP with new Hello message for peer 737 auto-discovery. One is based on reusing BGP OPEN message format for 738 peer auto-discovery. One is based on bootstrapping BGP sessions via 739 existing BGP sessions. One is based upon bootstraping a BGP Route 740 Reflector via the OSPF protocol. 742 A.3.1. New BGP Hello Message based Approach 744 [I-D.xu-idr-neighbor-autodiscovery] describes a BGP neighbor 745 discovery mechanism which is based on a newly defined UDP based BGP 746 Hello message. The BGP Hello message is sent in multicast to 747 discover the directly connected BGP peers. According to the message 748 header format and the TLVs carried in the message, the information 749 which can be signaled is: 751 o AS number 752 o BGP Identifier 753 o Accepted ASN list 754 o Peering address (IPv4 or IPv6) 755 o Local prefix (for loopback) 756 o Link attributes 757 o Neighbor state 758 o BGP Authentication 760 The mechanisms in this draft do not currently handle fragmentation. 762 The mechanism in this draft is perhaps unique among the other 763 proposals in requiring bi-directional state. 765 A.3.2. BGP OPEN Message based Approach 767 [I-D.raszuk-idr-bgp-auto-session-setup] describes a BGP neighbor 768 discovery mechanism by reusing BGP OPEN message format with newly 769 defined UDP port. The message is called BGP Session Explorer (BSE) 770 packet and is sent in multicast. Since the message format is the 771 same as BGP OPEN, the information which can be signaled is: 773 o AS number 774 o BGP Identifier 775 o Peering address 777 The mechanism is currently under-specified with respect to a number 778 of similar properties described elsewhere. A general implication is 779 that those properties - and others providing for extensibility of the 780 auto-discovery mechanism - would need to be added to the BGP OPEN 781 message and deal with the related impacts on the BGP session's 782 finite-state machine. 784 BGP PDUs, including the OPEN message, may be up to 4k in size. Since 785 this mechanism leverages Layer 3 multicast, a PDU fragmentation 786 mechanism may need to be described. 788 A.3.3. Bootstrapping BGP via BGP 790 [I-D.raszuk-idr-bgp-auto-discovery] describes a new BGP address 791 family. The NLRI carries a Group ID + BGP Identifier as the key. A 792 new BGP Path Attribute carries information about the sessions: 794 o AS Number 795 o AFI/SAFI 796 o BGP Identifier 797 o Peer Transport Address 798 o Flags to declare a session for information only, to force a reset 799 of a session on parameter changes, etc. 801 Since the BGP auto-discovery state is carried by BGP, it inherits the 802 security implications of the underlying BGP session. 804 PDU size considerations are identical to those of a BGP UPDATE 805 message. 807 Similarly, extensibility considerations would rely on either the new 808 BGP Path Attribute, or one yet to be defined. 810 A.3.4. Bootstrapping BGP via OSPF 812 [I-D.acee-ospf-bgp-rr] describes a mechanism to learn BGP Route 813 Reflectors via OSPFv2/OSPFv3 LSAs. Multiple types of scopes are 814 defined for these LSAs to help constrain where they are advertised in 815 an OSPF domain. 817 The BGP Route Reflector TLV contains: 819 o Local AS Number 820 o IPv4 or IPv6 Address of the Route Reflector 821 o A list of AFI/SAFIs supported by the Route Reflector 823 The BGP Route Reflector TLV may be advertised more than once, 824 potentially to describe different IP transport endpoints. 826 This mechanism does not provide for security properties of the BGP 827 session or transport properties such as BFD or GTSM. 829 Authors' Addresses 831 Randy Bush 832 Arrcus, Inc. & Internet Initiative Japan 833 5147 Crystal Springs 834 Bainbridge Island, WA 98110 835 US 837 Email: randy@psg.com 839 Jie Dong 840 Huawei Technologies 841 Huawei Campus, No. 156 Beiqing Road 842 Beijing 100095 843 China 845 Email: jie.dong@huawei.com 847 Jeffrey Haas (editor) 848 Juniper Networks 849 1133 Innovation Way 850 Sunnyvale, CA 94089 851 US 853 Email: jhaas@juniper.net 854 Warren Kumari (editor) 855 Google 856 1600 Amphitheatre Parkway 857 Mountain View, CA 94043 858 US 860 Email: warren@kumari.net