idnits 2.17.1 draft-ietf-lsvr-l3dl-ulpc-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 date (May 26, 2020) is 1424 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 (-12) exists of draft-ietf-lsvr-l3dl-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-lsvr-l3dl (ref. 'I-D.ietf-lsvr-l3dl') ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-29) exists of draft-ietf-lsvr-bgp-spf-09 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 2 errors (**), 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: November 27, 2020 Arrcus 6 May 26, 2020 8 L3DL Upper Layer Protocol Configuration 9 draft-ietf-lsvr-l3dl-ulpc-00 11 Abstract 13 This document users 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 November 27, 2020. 43 Copyright Notice 45 Copyright (c) 2020 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Reading and Terminology . . . . . . . . . . . . . . . . . . . 2 62 3. Upper Layer Protocol Configuration PDU . . . . . . . . . . . 3 63 3.1. BGP ULPC Attribute sub-TLVs . . . . . . . . . . . . . . . 3 64 3.1.1. BGP ASN . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. BGP IPv4 Address . . . . . . . . . . . . . . . . . . 5 66 3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5 67 3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 6 68 3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 6.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Massive Data Centers (MDCs) which use upper layer protocols such as 79 BGP4, BGP-LS, BGP-SPF, etc. may use the Layer 3 Liveness and 80 Discovery Protocol, L3DP, [I-D.ietf-lsvr-l3dl] 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 L3DP 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 Discovery and Liveness 90 [I-D.ietf-lsvr-l3dl]. The terminology and PDUs there are assumed 91 here. 93 Familiarity with the BGP4 Protocol [RFC4271] is assumed. Familiarity 94 with BGP-SPF, [I-D.ietf-lsvr-bgp-spf], might be useful. 96 3. Upper Layer Protocol Configuration PDU 98 To communicate parameters required to configure peering and operation 99 of Upper Layer Protocols at IP layer 3 and above, e.g., BGP sessions 100 on a link, a neutral sub-TLV based Upper Layer Protocol PDU is 101 defined as follows: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Type = 9 | Payload Length ~ 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 ~ | ULPC Type | AttrCount | ~ 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 ~ Attribute List ... | Sig Type | Signature Len ~ 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 ~ | Signature ... | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl]. 117 ULPC Type: An integer denoting the type of the uper layer protocol 119 0 : Reserved 120 1 : BGP 121 2-255 : Reserved 123 The AttrCount is the number of attribute sub-TLVs in the Attribute 124 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. BGP ULPC 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 multiple sets of BGP sub-TLVs MAY BE exchanged within the BGP 153 ULPC PDU or multiple BGP ULPC PDUs may be sent, one for each address 154 family. 156 A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU for 157 an particular address family at any point in time; receipt of a new 158 BGP ULPC PDU for a particular address family replaces any previous 159 one. 161 If there are one or more open BGP sessions, receipt of a new BGP ULPC 162 PDU does not affect these sessions and the PDU SHOULD be discarded. 163 If a peer wishes to replace an open BGP session, they must first 164 close the running session and then send a new BGP ULPC PDU. 166 As a link may have multiple encapsulations and multiple addresses for 167 an IP encapsulation, which address of which encapsulation is to be 168 used for the BGP session MUST be specified. 170 For each BGP peering on a link here MUST be one agreed encapsulation, 171 and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 172 Announcement PDUs. If the choice is ambiguous, an Attribute may be 173 used to signal preferences. 175 If a peering address has been announced as a loopback, i.e. MUST BE 176 flagged as such in the L3DL Encapsulation PDU, a two or three hop BGP 177 session will be established. Otherwise a direct one hop session is 178 used. the BGP session to a loopback will forward to the peer's 179 address which was marked as Primary in the L3DL Encapsulation Flags, 180 iff it is in a subnet which is shared with both BGP speakers. If the 181 primary is not in a common subnet, then the BGP speaker MAY pick a 182 forwarding next hop that is in a subnet they share. If there are 183 multiple choices, the BGP speaker SHOULD have signaled which subnet 184 to choose in an 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 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: Ghu knows what 271 Bit 1-15: Must be zero 273 4. Security Considerations 275 All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this 276 PDU. 278 As the ULPC PDU may contain keying material, see Section 3.1.4, it 279 SHOULD BE signed. 281 Any keying material in the PDU SHOULD BE salted and hashed. 283 The BGP Authentication sub-TLV provides for provisioning MD5, which 284 is a quite weak hash, horribly out of fashion, and kills puppies. 285 But, like it or not, it has been sufficient against the kinds of 286 attacks BGP TCP sessions have endured. Soit is what BGP deployments 287 use. 289 5. IANA Considerations 291 This document requests the IANA create a new entry in the L3DL PDU 292 Type registry as follows: 294 PDU 295 Code PDU Name 296 ---- ------------------- 297 9 ULPC 299 This document requests the IANA create a registry for L3DL ULPC Type, 300 which may range from 0 to 255. The name of the registry should be 301 L3DL-ULPC-Type. The policy for adding to the registry is RFC 302 Required per [RFC5226], either standards track or experimental. The 303 initial entries should be the following: 305 Value Name 306 ----- ------------------- 307 0 Reserved 308 1 BGP 309 2-255 Reserved 311 6. References 313 6.1. Normative References 315 [I-D.ietf-lsvr-l3dl] 316 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 317 and Liveness", draft-ietf-lsvr-l3dl-04 (work in progress), 318 May 2020. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 326 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 327 DOI 10.17487/RFC4271, January 2006, 328 . 330 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 331 "Multiprotocol Extensions for BGP-4", RFC 4760, 332 DOI 10.17487/RFC4760, January 2007, 333 . 335 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 336 IANA Considerations Section in RFCs", RFC 5226, 337 DOI 10.17487/RFC5226, May 2008, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 6.2. Informative References 346 [I-D.ietf-lsvr-bgp-spf] 347 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 348 "Shortest Path Routing Extensions for BGP Protocol", 349 draft-ietf-lsvr-bgp-spf-09 (work in progress), May 2020. 351 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 352 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 353 1998, . 355 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 356 RFC 4808, DOI 10.17487/RFC4808, March 2007, 357 . 359 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 360 "Database of Long-Lived Symmetric Cryptographic Keys", 361 RFC 7210, DOI 10.17487/RFC7210, April 2014, 362 . 364 Authors' Addresses 366 Randy Bush 367 Arrcus & IIJ 368 5147 Crystal Springs 369 Bainbridge Island, WA 98110 370 US 372 Email: randy@psg.com 374 Keyur Patel 375 Arrcus 376 2077 Gateway Place, Suite #400 377 San Jose, CA 95119 378 United States of America 380 Email: keyur@arrcus.com