idnits 2.17.1 draft-ymbk-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 (November 2, 2019) is 1629 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-02 ** 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-06 -- 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: May 5, 2020 Arrcus 6 November 2, 2019 8 L3DL Upper Layer Protocol Configuration 9 draft-ymbk-lsvr-l3dl-ulpc-02 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 May 5, 2020. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . . . . . . 5 68 3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 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 a peering address has been announced as a 173 loopback, a two or three (one or both ends could be loopbacks) hop 174 BGP session will be established. Otherwise a direct one hop session 175 is used. 177 3.1.1. BGP ASN 179 The Autonomous System number MUST be specified. If the AS Number is 180 less than 32 bits, it is padded with high order zeros. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Attr Type = 1 | Attr Len = 6 | My ASN ~ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ~ | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 3.1.2. BGP IPv4 Address 192 The BGP IPv4 Address sub-TLV announces the sender's IPv4 BGP peering 193 source address to be used by the receiver. At least one of IPv4 or 194 IPv6 BGP source addresses MUST be announced. 196 As usual, the BGP OPEN capability negotiation will determine the AFI/ 197 SAFIs to be transported over the peering, see [RFC4760] . 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Attr Type = 2 | Attr Len = 7 | My IPv4 Peering Address ~ 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 ~ | Prefix Len | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 3.1.3. BGP IPv6 Address 209 The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP peering 210 source address to be used by the receiver. At least one of IPv4 or 211 IPv6 BGP source addresses MUST be announced. 213 As usual, the BGP OPEN capability negotiation will determine the AFI/ 214 SAFIs to be transported over the peering, see [RFC4760] . 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Attr Type = 3 | Attr Len = 19 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 221 | | 222 + + 223 | My IPv6 Peering Address | 224 + + 225 | | 226 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | Prefix Len | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 3.1.4. BGP Authentication sub-TLV 232 The BGP Authentication sub-TLV provides any authentication data 233 needed to OPEN the BGP session. Depending on operator configuration 234 of the environment, it might be a simple MD5 key (see [RFC2385]), the 235 name of a key chain a KARP database (see [RFC7210]), or one of 236 multiple Authentication sub-TLVs to support hop[RFC4808]. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Attr Type = 4 | Attr Len | ~ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 243 ~ BGP Authentication Data ... ~ 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 3.1.5. BGP Miscellaneous Flags 248 The BGP session OPEN has extensive, and a bit complex, capability 249 negotiation facilities. In case one or more extra attributes might 250 be needed, the BGP Miscellaneous Flags sub-TLV may be used. No flags 251 are currently defined. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Attr Type = 5 | Attr Len = 4 | Misc Flags | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Misc Attrs: 261 Bit 0: Ghu knows what 262 Bit 1-15: Must be zero 264 4. Security Considerations 266 All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this 267 PDU. 269 As the ULPC PDU may contain keying material, see Section 3.1.4, it 270 SHOULD BE signed. 272 Any keying material in the PDU SHOULD BE salted ad hashed. 274 The BGP Authentication sub-TLV provides for provisioning MD5, which 275 is a quite weak hash, horribly out of fashion, and kills puppies. 276 But, like it or not, it is what BGP deployments use. 278 5. IANA Considerations 280 This document requests the IANA create a new entry in the L3DL PDU 281 Type registry as follows: 283 PDU 284 Code PDU Name 285 ---- ------------------- 286 9 ULPC 288 This document requests the IANA create a registry for L3DL ULPC Type, 289 which may range from 0 to 255. The name of the registry should be 290 L3DL-ULPC-Type. The policy for adding to the registry is RFC 291 Required per [RFC5226], either standards track or experimental. The 292 initial entries should be the following: 294 Value Name 295 ----- ------------------- 296 0 Reserved 297 1 BGP 298 2-255 Reserved 300 6. References 302 6.1. Normative References 304 [I-D.ietf-lsvr-l3dl] 305 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 306 and Liveness", draft-ietf-lsvr-l3dl-02 (work in progress), 307 July 2019. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 315 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 316 DOI 10.17487/RFC4271, January 2006, 317 . 319 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 320 "Multiprotocol Extensions for BGP-4", RFC 4760, 321 DOI 10.17487/RFC4760, January 2007, 322 . 324 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 325 IANA Considerations Section in RFCs", RFC 5226, 326 DOI 10.17487/RFC5226, May 2008, 327 . 329 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 330 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 331 May 2017, . 333 6.2. Informative References 335 [I-D.ietf-lsvr-bgp-spf] 336 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 337 "Shortest Path Routing Extensions for BGP Protocol", 338 draft-ietf-lsvr-bgp-spf-06 (work in progress), September 339 2019. 341 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 342 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 343 1998, . 345 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 346 RFC 4808, DOI 10.17487/RFC4808, March 2007, 347 . 349 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 350 "Database of Long-Lived Symmetric Cryptographic Keys", 351 RFC 7210, DOI 10.17487/RFC7210, April 2014, 352 . 354 Authors' Addresses 356 Randy Bush 357 Arrcus & IIJ 358 5147 Crystal Springs 359 Bainbridge Island, WA 98110 360 US 362 Email: randy@psg.com 364 Keyur Patel 365 Arrcus 366 2077 Gateway Place, Suite #400 367 San Jose, CA 95119 368 United States of America 370 Email: keyur@arrcus.com