idnits 2.17.00 (12 Aug 2021) /tmp/idnits7731/draft-ietf-lsvr-l3dl-ulpc-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: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If there are one or more open BGP sessions, receipt of a new BGP ULPC PDU SHOULD not affect these sessions. The received data are stored for a future session restart. -- The document date (2 May 2022) is 12 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-lsvr-l3dl-08 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 1 error (**), 0 flaws (~~), 2 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 & IIJ 4 Intended status: Standards Track K. Patel 5 Expires: 3 November 2022 Arrcus 6 2 May 2022 8 L3DL Upper-Layer Protocol Configuration 9 draft-ietf-lsvr-l3dl-ulpc-03 11 Abstract 13 This document uses the Layer-3 Liveness and Discovery protocol to 14 communicate the parameters needed to exchange inter-device Upper 15 Layer Protocol Configuration for upper-layer protocols such as the 16 BGP family. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 [RFC2119] [RFC8174] when, and only when, they appear in all 24 capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 3 November 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2 61 3. Upper-Layer Protocol Configuration PDU . . . . . . . . . . . 3 62 3.1. ULPC BGP Attribute sub-TLVs . . . . . . . . . . . . . . . 4 63 3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5 65 3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5 66 3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6 67 3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 6.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Massive Data Centers (MDCs) which use upper-layer protocols such as 78 BGP4, BGP-LS, BGP-SPF, etc. may use the Layer-3 Liveness and 79 Discovery Protocol, L3DP, [I-D.ietf-lsvr-l3dl] to reveal the inter- 80 device links of the topology. It is desirable for devices to 81 facilitate the configuration parameters of those upper layer 82 protocols to enable more hands-free configuration. This document 83 defines a new L3DL PDU to communicate these Upper-Layer Protocol 84 Configuration parameters. 86 2. Reading and Terminology 88 The reader is assumed to have read Layer-3 Discovery and Liveness 89 [I-D.ietf-lsvr-l3dl]. The terminology and PDUs there are assumed 90 here. 92 Familiarity with the BGP4 Protocol [RFC4271] is assumed. Familiarity 93 with BGP-SPF, [I-D.ietf-lsvr-bgp-spf], might be useful. 95 3. Upper-Layer Protocol Configuration PDU 97 To communicate parameters required to configure peering and operation 98 of Upper-Layer Protocols at IP layer-3 and above, e.g., BGP sessions 99 on a link, a neutral sub-TLV based Upper-Layer Protocol PDU is 100 defined as follows: 102 0 1 2 3 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Type = 9 | Payload Length ~ 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 ~ | ULPC Type | AttrCount | ~ 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 ~ Attribute List ... | Sig Type | Signature Len ~ 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 ~ | Signature ... | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl]. 116 ULPC Type: A one octet integer denoting the type of the upper-layer 117 protocol 119 0 : Reserved 120 1 : BGP 121 2-255 : Reserved 123 The one octet AttrCount is the number of attribute sub-TLVs in the 124 Attribute List. 126 The Attribute List is a, possibly null, set of sub-TLVs describing 127 the configuration attributes of the specific upper-layer protocol. 129 An Attribute consists of a one octet Attribute Type, a one octet 130 Attribute Length of the number of octets in the Attribute, and a 131 Payload of arbitrary length up to 253 octets. 133 0 1 2 3 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Attr Type = 1 | Attr Len | Payload | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 3.1. ULPC BGP Attribute sub-TLVs 141 The parameters needed for BGP peering on a link are exchanged in sub- 142 TLVs within an Upper-Layer Protocol PDU. The following describe the 143 various sub-TLVs for BGP. 145 The goal is to provide the minimal set of configuration parameters 146 needed by BGP OPEN to successfully start a BGP peering. The goal is 147 specifically not to replace or conflict with data exchanged during 148 BGP OPEN. Multiple sources of truth are a recipe for complexity and 149 hence pain. 151 If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6, 152 then separate BGP ULPC PDUs should be sent, one for each address 153 family. 155 A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for 156 an particular address family on a specific link at any point in time; 157 receipt of a new BGP ULPC PDU for a particular address family 158 replaces the data any previous one; but does not actually affect the 159 session. 161 If there are one or more open BGP sessions, receipt of a new BGP ULPC 162 PDU SHOULD not affect these sessions. The received data are stored 163 for a future session restart. 165 As a link may have multiple encapsulations and multiple addresses for 166 an IP encapsulation, which address of which encapsulation is to be 167 used for the BGP session MUST be specified. 169 For each BGP peering on a link here MUST be one agreed encapsulation, 170 and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 171 Announcement PDUs. If the choice is ambiguous, an Attribute may be 172 used to signal preferences. 174 If a peering address has been announced as a loopback, i.e. MUST BE 175 flagged as such in the L3DL Encapsulation PDU (see 176 [I-D.ietf-lsvr-l3dl] Sec. 13.2), a two or three hop BGP session will 177 be established. Otherwise a direct one hop session is used. The BGP 178 session to a loopback will forward to the peer's address which was 179 marked as Primary in the L3DL Encapsulation Flags, iff it is in a 180 subnet which is shared with both BGP speakers. If the primary is not 181 in a common subnet, then the BGP speaker MAY pick a forwarding next 182 hop that is in a subnet they share. If there are multiple choices, 183 the BGP speaker SHOULD have signaled which subnet to choose in an 184 Upper-Layer Protocol Configuration PDU Attribute. 186 Attributes MUST be unique in the Attribute List. I.e. a particular 187 Attr Type MUST NOT occur more than once in the Attribute List. If a 188 ULPC PDU is received with more than one occurrence of a particular 189 Attr Type, an Error ACK MUST be returned. 191 As there are separate PDU Attr Types for IPv4 and IPv6 peering 192 addresses, separate sessions for the two AFIs MAY be created for the 193 same ASN in one ULPC PDU. 195 3.1.1. BGP ASN 197 The four octet Autonomous System number MUST be specified. If the AS 198 Number is less than 32 bits, it is padded with high order zeros. 200 0 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Attr Type = 1 | Attr Len = 6 | My ASN ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ~ | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 3.1.2. BGP IPv4 Address 210 The four octet BGP IPv4 Address sub-TLV announces the sender's IPv4 211 BGP peering source address to be used by the receiver. At least one 212 of IPv4 or IPv6 BGP source addresses MUST be announced. 214 As usual, the BGP OPEN capability negotiation will determine the AFI/ 215 SAFIs to be transported over the peering, see [RFC4760] . 217 0 1 2 3 218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Attr Type = 2 | Attr Len = 5 | My IPv4 Peering Address ~ 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 ~ | Prefix Len | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 3.1.3. BGP IPv6 Address 227 The BGP IPv6 Address sub-TLV announces the sender's 16 octet IPv6 BGP 228 peering source address and one octet Prefix Length to be used by the 229 receiver. At least one of IPv4 or IPv6 BGP source addresses MUST be 230 announced. 232 As usual, the BGP OPEN capability negotiation will determine the AFI/ 233 SAFIs to be transported over the peering, see [RFC4760]. 235 0 1 2 3 236 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Attr Type = 3 | Attr Len = 17 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 240 | | 241 + + 242 | My IPv6 Peering Address | 243 + + 244 | | 245 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | Prefix Len | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 3.1.4. BGP Authentication sub-TLV 251 The BGP Authentication sub-TLV provides any authentication data 252 needed to OPEN the BGP session. Depending on operator configuration 253 of the environment, it might be a simple MD5 key (see [RFC2385]), the 254 name of a key chain in a KARP database (see [RFC7210]), or one of 255 multiple Authentication sub-TLVs to support hop[RFC4808]. 257 0 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Attr Type = 4 | Attr Len | ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 262 ~ BGP Authentication Data ... ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 3.1.5. BGP Miscellaneous Flags 267 The BGP session OPEN has extensive, and a bit complex, capability 268 negotiation facilities. In case one or more extra attributes might 269 be needed, the two octet BGP Miscellaneous Flags sub-TLV may be used. 270 No flags are currently defined. 272 0 1 2 3 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Attr Type = 5 | Attr Len = 4 | Misc Flags | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Misc Flags: 280 Bit 0: GTSM 282 Bit 1: BFD 283 Bit 2-15: Must be zero 285 The GTSM flag, when 1, indicates that the sender wishes to enable the 286 [RFC5082] Generalized TTL Security Mechanism for the session. 288 The BFD flag, when 1, indicates that the sender wishes to enable the 289 [RFC5880] Bidirectional Forwarding Detection for the session. 291 4. Security Considerations 293 All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this 294 PDU. 296 As the ULPC PDU may contain keying material, see Section 3.1.4, it 297 SHOULD BE signed. 299 Any keying material in the PDU SHOULD BE salted and hashed. 301 The BGP Authentication sub-TLV provides for provisioning MD5, which 302 is a quite weak hash, horribly out of fashion, and kills puppies. 303 But, like it or not, it has been sufficient against the kinds of 304 attacks BGP TCP sessions have endured. So it is what BGP deployments 305 use. 307 5. IANA Considerations 309 This document requests the IANA create a new entry in the L3DL PDU 310 Type registry as follows: 312 PDU 313 Code PDU Name 314 ---- ------------------- 315 9 ULPC 317 This document requests the IANA create a registry for L3DL ULPC Type, 318 which may range from 0 to 255. The name of the registry should be 319 L3DL-ULPC-Type. The policy for adding to the registry is RFC 320 Required per [RFC5226], either standards track or experimental. The 321 initial entries should be the following: 323 Value Name 324 ----- ------------------- 325 0 Reserved 326 1 BGP 327 2-255 Reserved 329 6. References 330 6.1. Normative References 332 [I-D.ietf-lsvr-l3dl] 333 Bush, R., Austein, R., and K. Patel, "Layer-3 Discovery 334 and Liveness", Work in Progress, Internet-Draft, draft- 335 ietf-lsvr-l3dl-08, 14 October 2021, 336 . 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 345 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 346 DOI 10.17487/RFC4271, January 2006, 347 . 349 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 350 "Multiprotocol Extensions for BGP-4", RFC 4760, 351 DOI 10.17487/RFC4760, January 2007, 352 . 354 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 355 Pignataro, "The Generalized TTL Security Mechanism 356 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 357 . 359 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 360 IANA Considerations Section in RFCs", RFC 5226, 361 DOI 10.17487/RFC5226, May 2008, 362 . 364 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 365 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 366 . 368 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 369 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 370 May 2017, . 372 6.2. Informative References 374 [I-D.ietf-lsvr-bgp-spf] 375 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, "BGP 376 Link-State Shortest Path First (SPF) Routing", Work in 377 Progress, Internet-Draft, draft-ietf-lsvr-bgp-spf-16, 15 378 February 2022, . 381 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 382 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 383 1998, . 385 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 386 RFC 4808, DOI 10.17487/RFC4808, March 2007, 387 . 389 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 390 "Database of Long-Lived Symmetric Cryptographic Keys", 391 RFC 7210, DOI 10.17487/RFC7210, April 2014, 392 . 394 Authors' Addresses 396 Randy Bush 397 Arrcus & IIJ 398 5147 Crystal Springs 399 Bainbridge Island, WA 98110 400 United States of America 401 Email: randy@psg.com 403 Keyur Patel 404 Arrcus 405 2077 Gateway Place, Suite #400 406 San Jose, CA 95119 407 United States of America 408 Email: keyur@arrcus.com