idnits 2.17.00 (12 Aug 2021) /tmp/idnits24230/draft-ymbk-idr-l3nd-ulpc-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (4 April 2022) is 40 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) ** 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 (~~), 1 warning (==), 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: 6 October 2022 Arrcus 6 4 April 2022 8 L3ND Upper-Layer Protocol Configuration 9 draft-ymbk-idr-l3nd-ulpc-05 11 Abstract 13 This document adds PDUs to the Layer-3 Neighbor 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 6 October 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 . . . . . . . . . . . . . . . . . . 6 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Massive Data Centers (MDCs) which use upper-layer protocols such as 79 BGP4 and other routing protocols may use the Layer-3 Neighbor 80 Discovery Protocol, L3ND, [I-D.ymbk-idr-l3nd] to reveal the inter- 81 device links of the topology. It is desirable for devices to 82 facilitate the configuration parameters of those upper layer 83 protocols to enable more hands-free configuration. This document 84 defines a new L3ND PDU to communicate these Upper-Layer Protocol 85 Configuration parameters. 87 2. Reading and Terminology 89 The reader is assumed to have read Layer-3 Neighbor Discovery 90 [I-D.ymbk-idr-l3nd]. The terminology and PDUs there are assumed 91 here. 93 Familiarity with the BGP4 Protocol [RFC4271] is assumed. 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 | Version = 0 | Type = 8 | Payload Length | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | | ULPC Type | AttrCount | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | Serial Number | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Attribute List ... | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 The Version, Type, and Payload Length as defined in 115 [I-D.ymbk-idr-l3nd] apply to this PDU. 117 The BGP Authentication sub-TLV provides for provisioning MD5, which 118 is a quite weak hash, horribly out of fashion, and kills puppies. 119 But, like it or not, it has been sufficient against the kinds of 120 attacks BGP TCP sessions have endured. So it is what BGP deployments 121 use. 123 As the ULPC PDU may contain keying material, e.g. [RFC2385], it 124 SHOULD BE over TLS. 126 ULPC Type: A one byte integer denoting the type of the upper-layer 127 protocol 129 0 : Reserved 130 1 : BGP 131 2-255 : Reserved 133 The one octet AttrCount is the number of attribute sub-TLVs in the 134 Attribute List. 136 The Attribute List is a, possibly null, set of sub-TLVs describing 137 the configuration attributes of the specific upper-layer protocol. 139 An Attribute consists of a one octet Attribute Type, a one octet 140 Attribute Length of the number of octets in the Attribute, and a 141 Payload of arbitrary length up to 253 octets. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Attr Type = 1 | Attr Len | Payload | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 3.1. ULPC BGP Attribute sub-TLVs 151 The parameters needed for BGP peering on a link are exchanged in sub- 152 TLVs within an Upper-Layer Protocol PDU. The following describe the 153 various sub-TLVs for BGP. 155 The goal is to provide the minimal set of configuration parameters 156 needed by BGP OPEN to successfully start a BGP peering. The goal is 157 specifically not to replace or conflict with data exchanged during 158 BGP OPEN. Multiple sources of truth are a recipe for complexity and 159 hence pain. 161 If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6, 162 then separate BGP ULPC PDUs should be sent, one for each address 163 family. 165 A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for 166 an particular address family on a specific link at any point in time; 167 receipt of a new BGP ULPC PDU for a particular address family 168 replaces the data any previous one; but does not actually affect the 169 session. 171 If there are one or more open BGP sessions, receipt of a new BGP ULPC 172 PDU SHOULD not affect these sessions. The received data are stored 173 for a future session restart. 175 As a link may have multiple encapsulations and multiple addresses for 176 an IP encapsulation, which address of which encapsulation is to be 177 used for the BGP session MUST be specified. 179 For each BGP peering on a link here MUST be one agreed encapsulation, 180 and the addresses used MUST be in the corresponding L3ND IPv4/IPv6 181 Encapsulation PDUs. If the choice is ambiguous, an Attribute may be 182 used to signal preferences. 184 If a peering address has been announced as a loopback, i.e. MUST BE 185 flagged as such in the L3ND Encapsulation PDU (see 186 [I-D.ymbk-idr-l3nd] Sec. 10.2), a two or three hop BGP session MUST 187 be established as needed. Otherwise a direct one hop session is 188 used. The BGP session to a loopback will forward to the peer's 189 address which was marked as Primary in the L3ND Encapsulation Flags, 190 iff it is in a subnet which is shared with both BGP speakers. If the 191 primary is not in a common subnet, then the BGP speaker MAY pick a 192 forwarding next hop that is in a subnet they share. If there are 193 multiple choices, the BGP speaker SHOULD have signaled which subnet 194 to choose in an Upper-Layer Protocol Configuration PDU Attribute. 196 Attributes MUST be unique in the Attribute List. I.e. a particular 197 Attr Type MUST NOT occur more than once in the Attribute List. If a 198 ULPC PDU is received with more than one occurrence of a particular 199 Attr Type, an Error ACK MUST be returned. 201 As there are separate PDU Attr Types for IPv4 and IPv6 peering 202 addresses, separate sessions for the two AFIs MAY be created for the 203 same ASN in one ULPC PDU. 205 3.1.1. BGP ASN 207 The four octet Autonomous System number MUST be specified. If the AS 208 Number is less than 32 bits, it is padded with high order zeros. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Attr Type = 1 | Attr Len = 4 | My ASN ~ 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 ~ | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 3.1.2. BGP IPv4 Address 220 The BGP IPv4 Address sub-TLV announces the sender's four octet IPv4 221 BGP peering source address and one octet Prefix Lenth to be used by 222 the receiver. At least one of IPv4 or IPv6 BGP source addresses MUST 223 be announced. 225 As usual, the BGP OPEN capability negotiation will determine the AFI/ 226 SAFIs to be transported over the peering, see [RFC4760]. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Attr Type = 2 | Attr Len = 5 | My IPv4 Peering Address ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ | Prefix Len | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 3.1.3. BGP IPv6 Address 238 The BGP IPv6 Address sub-TLV announces the sender's 16 octet IPv6 BGP 239 peering source address and one octet Prefix Length to be used by the 240 receiver. At least one of IPv4 or IPv6 BGP source addresses MUST be 241 announced. 243 As usual, the BGP OPEN capability negotiation will determine the AFI/ 244 SAFIs to be transported over the peering, see [RFC4760]. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Attr Type = 3 | Attr Len = 17 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 251 | | 252 + + 253 | My IPv6 Peering Address | 254 + + 255 | | 256 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | Prefix Len | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 3.1.4. BGP Authentication sub-TLV 262 The BGP Authentication sub-TLV provides any authentication data 263 needed to OPEN the BGP session. Depending on operator configuration 264 of the environment, it might be a simple MD5 key (see [RFC2385]), the 265 name of a key chain in a KARP database (see [RFC7210]), or one of 266 multiple Authentication sub-TLVs to support hop[RFC4808]. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Attr Type = 4 | Attr Len | ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 273 ~ BGP Authentication Data ... ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 3.1.5. BGP Miscellaneous Flags 278 The BGP session OPEN has extensive, and a bit complex, capability 279 negotiation facilities. In case one or more extra attributes might 280 be needed, the two octet BGP Miscellaneous Flags sub-TLV may be used. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Attr Type = 5 | Attr Len = 2 | Misc Flags | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Misc Flags: 290 Bit 0: GTSM 292 Bit 1: BFD 294 Bit 2-15: Must be zero 296 The GTSM flag, when 1, indicates that the sender wishes to enable the 297 [RFC5082] Generalized TTL Security Mechanism for the session. 299 The BFD flag, when 1, indicates that the sender wishes to enable the 300 [RFC5880] Bidirectional Forwarding Detection for the session. 302 4. Security Considerations 304 All the Security considerations of [I-D.ymbk-idr-l3nd] apply to this 305 PDU. 307 As the ULPC PDU may contain keying material, see Section 3.1.4, it 308 SHOULD BE over TLS, not clear TCP. 310 Any keying material in the PDU SHOULD BE salted and hashed. 312 The BGP Authentication sub-TLV provides for provisioning MD5, which 313 is a quite weak hash, horribly out of fashion, and kills puppies. 314 But, like it or not, it has been sufficient against the kinds of 315 attacks BGP TCP sessions have endured. So it is what BGP deployments 316 use. 318 5. IANA Considerations 320 This document requests the IANA create a new entry in the L3ND PDU 321 Type registry as follows: 323 PDU 324 Code PDU Name 325 ---- ------------------- 326 9 ULPC 328 This document requests the IANA create a registry for L3ND ULPC Type, 329 which may range from 0 to 255. The name of the registry should be 330 L3ND-ULPC-Type. The policy for adding to the registry is RFC 331 Required per [RFC5226], either standards track or experimental. The 332 initial entries should be the following: 334 Value Name 335 ----- ------------------- 336 0 Reserved 337 1 BGP 338 2-255 Reserved 340 6. Acknowledgments 342 The authors thank Rob Austein, Sue Hares, and Russ Housley. 344 7. References 346 7.1. Normative References 348 [I-D.ymbk-idr-l3nd] 349 Bush, R., Housley, R., Austein, R., Hares, S., and K. 350 Patel, "Layer-3 Neighbor Discovery", Work in Progress, 351 Internet-Draft, draft-ymbk-idr-l3nd-04, 4 April 2022, 352 . 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 361 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 362 DOI 10.17487/RFC4271, January 2006, 363 . 365 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 366 "Multiprotocol Extensions for BGP-4", RFC 4760, 367 DOI 10.17487/RFC4760, January 2007, 368 . 370 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 371 Pignataro, "The Generalized TTL Security Mechanism 372 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 373 . 375 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 376 IANA Considerations Section in RFCs", RFC 5226, 377 DOI 10.17487/RFC5226, May 2008, 378 . 380 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 381 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 382 . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 7.2. Informative References 390 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 391 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 392 1998, . 394 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 395 RFC 4808, DOI 10.17487/RFC4808, March 2007, 396 . 398 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 399 "Database of Long-Lived Symmetric Cryptographic Keys", 400 RFC 7210, DOI 10.17487/RFC7210, April 2014, 401 . 403 Authors' Addresses 405 Randy Bush 406 Arrcus & IIJ 407 5147 Crystal Springs 408 Bainbridge Island, WA 98110 409 United States of America 410 Email: randy@psg.com 412 Keyur Patel 413 Arrcus 414 2077 Gateway Place, Suite #400 415 San Jose, CA 95119 416 United States of America 417 Email: keyur@arrcus.com