idnits 2.17.00 (12 Aug 2021) /tmp/idnits57147/draft-ietf-lsvr-l3dl-ulpc-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 date (14 October 2021) is 219 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-07 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-16) exists of draft-ietf-lsvr-bgp-spf-15 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 1 error (**), 0 flaws (~~), 3 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: 17 April 2022 Arrcus 6 14 October 2021 8 L3DL Upper-Layer Protocol Configuration 9 draft-ietf-lsvr-l3dl-ulpc-02 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 23 BCP 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 17 April 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified 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. BGP ULPC Attribute sub-TLVs . . . . . . . . . . . . . . . 3 63 3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 6.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 L3DP 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: An integer denoting the type of the upper-layer protocol 118 0 : Reserved 119 1 : BGP 120 2-255 : Reserved 122 The AttrCount is the number of attribute sub-TLVs in the Attribute 123 List. 125 The Attribute List is a, possibly null, set of sub-TLVs describing 126 the configuration attributes of the specific upper-layer protocol. 128 An Attribute consists of a one octet Attribute Type, a one octet 129 Attribute Length of the number of octets in the Attribute, and a 130 Payload of arbitrary length up to 253 octets. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Attr Type = 1 | Attr Len | Payload | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 3.1. BGP ULPC Attribute sub-TLVs 140 The parameters needed for BGP peering on a link are exchanged in sub- 141 TLVs within an Upper-Layer Protocol PDU. The following describe the 142 various sub-TLVs for BGP. 144 The goal is to provide the minimal set of configuration parameters 145 needed by BGP OPEN to successfully start a BGP peering. The goal is 146 specifically not to replace or conflict with data exchanged during 147 BGP OPEN. Multiple sources of truth are a recipe for complexity and 148 hence pain. 150 If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6, 151 then multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP 152 ULPC PDU or multiple BGP ULPC PDUs may 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 at any point in time; receipt of a new 157 BGP ULPC PDU for a particular address family replaces any previous 158 one. 160 If there are one or more open BGP sessions, receipt of a new BGP ULPC 161 PDU does not affect these sessions and the PDU SHOULD be discarded. 162 If a peer wishes to replace an open BGP session, they must first 163 close the running session and then send a new BGP ULPC PDU. 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 3.1.1. BGP ASN 188 The Autonomous System number MUST be specified. If the AS Number is 189 less than 32 bits, it is padded with high order zeros. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Attr Type = 1 | Attr Len = 6 | My ASN ~ 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 ~ | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 3.1.2. BGP IPv4 Address 201 The BGP IPv4 Address sub-TLV announces the sender's IPv4 BGP peering 202 source address to be used by the receiver. At least one of IPv4 or 203 IPv6 BGP source addresses MUST be announced. 205 As usual, the BGP OPEN capability negotiation will determine the AFI/ 206 SAFIs to be transported over the peering, see [RFC4760] . 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Attr Type = 2 | Attr Len = 7 | My IPv4 Peering Address ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ~ | Prefix Len | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 3.1.3. BGP IPv6 Address 218 The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP peering 219 source address to be used by the receiver. At least one of IPv4 or 220 IPv6 BGP source addresses MUST be announced. 222 As usual, the BGP OPEN capability negotiation will determine the AFI/ 223 SAFIs to be transported over the peering, see [RFC4760] . 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Attr Type = 3 | Attr Len = 19 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 230 | | 231 + + 232 | My IPv6 Peering Address | 233 + + 234 | | 235 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | Prefix Len | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 3.1.4. BGP Authentication sub-TLV 241 The BGP Authentication sub-TLV provides any authentication data 242 needed to OPEN the BGP session. Depending on operator configuration 243 of the environment, it might be a simple MD5 key (see [RFC2385]), the 244 name of a key chain in a KARP database (see [RFC7210]), or one of 245 multiple Authentication sub-TLVs to support hop[RFC4808]. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Attr Type = 4 | Attr Len | ~ 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 252 ~ BGP Authentication Data ... ~ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 3.1.5. BGP Miscellaneous Flags 257 The BGP session OPEN has extensive, and a bit complex, capability 258 negotiation facilities. In case one or more extra attributes might 259 be needed, the BGP Miscellaneous Flags sub-TLV may be used. No flags 260 are currently defined. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Attr Type = 5 | Attr Len = 4 | Misc Flags | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Misc Attrs: 270 Bit 0: GTSM 272 Bit 1-15: Must be zero 274 The GTSM flag indicates that the sender wishes to enable the 275 [RFC5682] Generalized TTL Security Mechanism for the session. 277 4. Security Considerations 279 All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this 280 PDU. 282 As the ULPC PDU may contain keying material, see Section 3.1.4, it 283 SHOULD BE signed. 285 Any keying material in the PDU SHOULD BE salted and hashed. 287 The BGP Authentication sub-TLV provides for provisioning MD5, which 288 is a quite weak hash, horribly out of fashion, and kills puppies. 289 But, like it or not, it has been sufficient against the kinds of 290 attacks BGP TCP sessions have endured. Soit is what BGP deployments 291 use. 293 5. IANA Considerations 295 This document requests the IANA create a new entry in the L3DL PDU 296 Type registry as follows: 298 PDU 299 Code PDU Name 300 ---- ------------------- 301 9 ULPC 303 This document requests the IANA create a registry for L3DL ULPC Type, 304 which may range from 0 to 255. The name of the registry should be 305 L3DL-ULPC-Type. The policy for adding to the registry is RFC 306 Required per [RFC5226], either standards track or experimental. The 307 initial entries should be the following: 309 Value Name 310 ----- ------------------- 311 0 Reserved 312 1 BGP 313 2-255 Reserved 315 6. References 317 6.1. Normative References 319 [I-D.ietf-lsvr-l3dl] 320 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 321 and Liveness", Work in Progress, Internet-Draft, draft- 322 ietf-lsvr-l3dl-07, 26 January 2021, 323 . 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 332 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 333 DOI 10.17487/RFC4271, January 2006, 334 . 336 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 337 "Multiprotocol Extensions for BGP-4", RFC 4760, 338 DOI 10.17487/RFC4760, January 2007, 339 . 341 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 342 IANA Considerations Section in RFCs", RFC 5226, 343 DOI 10.17487/RFC5226, May 2008, 344 . 346 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 347 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 348 Spurious Retransmission Timeouts with TCP", RFC 5682, 349 DOI 10.17487/RFC5682, September 2009, 350 . 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017, . 356 6.2. Informative References 358 [I-D.ietf-lsvr-bgp-spf] 359 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, "BGP 360 Link-State Shortest Path First (SPF) Routing", Work in 361 Progress, Internet-Draft, draft-ietf-lsvr-bgp-spf-15, 1 362 July 2021, . 365 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 366 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 367 1998, . 369 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 370 RFC 4808, DOI 10.17487/RFC4808, March 2007, 371 . 373 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 374 "Database of Long-Lived Symmetric Cryptographic Keys", 375 RFC 7210, DOI 10.17487/RFC7210, April 2014, 376 . 378 Authors' Addresses 379 Randy Bush 380 Arrcus & IIJ 381 5147 Crystal Springs 382 Bainbridge Island, WA 98110 383 United States of America 385 Email: randy@psg.com 387 Keyur Patel 388 Arrcus 389 2077 Gateway Place, Suite #400 390 San Jose, CA 95119 391 United States of America 393 Email: keyur@arrcus.com