idnits 2.17.1 draft-ymbk-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 (April 27, 2019) is 1818 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-00 ** 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-04 -- 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: October 29, 2019 Arrcus 6 April 27, 2019 8 L3DL Upper Layer Protocol Configuration 9 draft-ymbk-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 October 29, 2019. 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 . . . . . . . . . . . . . . . . . . 4 66 3.1.3. BGP IPv6 Address . . . . . . . . . . . . . . . . . . 5 67 3.1.4. BGP Authentication sub-TLV . . . . . . . . . . . . . 5 68 3.1.5. BGP Miscellaneous Flags . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 7 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 = 8 | Payload Length | ULPC Type | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | AttrCount | Attribute List ... ~ 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Sig Type | Signature Length | Signature ... ~ 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 The Type and Payload Length are defined in [I-D.ietf-lsvr-l3dl]. 115 ULPC Type: 117 Bit 0 : BGP 118 Bit 1-15: Must be 0 120 The AttrCount is the number of attribute sub-TLVs in the Attribute 121 List. 123 The Attribute List is a, possibly null, set of sub-TLVs describing 124 the configuration attributes of the specific upper layer protocol. 126 3.1. BGP ULPC Attribute sub-TLVs 128 The parameters needed for BGP peering on a link are exchanged in sub- 129 TLVs within an Upper Layer Protocol PDU. The following describe the 130 various sub-TLVs for BGP. 132 The goal is to provide the minimal set of configuration parameters 133 needed by BGP OPEN to successfully start a BGP peering. The goal is 134 specifically not to replace or conflict with data exchanged during 135 BGP OPEN. Multiple sources of truth are a recipe for complexity and 136 hence pain. 138 If there are multiple BGP sessions on a link, e.g., IPv4 and IPv6, 139 then multiple sets of BGP sub-TLVs are exchanged within the BGP ULPC 140 PDU. 142 A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU at 143 any point in time; receipt of a new BGP ULPC PDU replaces any 144 previous one. If there are one or more open BGP sessions, receipt of 145 a new BGP ULPC PDU does not affect these sessions. 147 As a link may have multiple encapsulations and multiple addresses for 148 an IP encapsulation, which address of which encapsulation are to be 149 used for the BGP session MUST be specified. 151 For each BGP peering on a link here MUST be one agreed encapsulation, 152 and the addresses used MUST be in the corresponding L3DP IPv4/IPv6 153 Announcement PDUs. If a peering address has been announced as a 154 loopback, a two or three (one or both ends could be loopbacks) hop 155 BGP session will be established. Otherwise a direct one hop session 156 is used. 158 3.1.1. BGP ASN 160 The Autonomous System number MUST be specified. If the AS Number is 161 less than 32 bits, it is padded with high order zeros. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Attr Type = 1 | Attr Len = 48 | My ASN ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 ~ | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 3.1.2. BGP IPv4 Address 173 The BGP IPv4 Address sub-TLV announces the sender's IPv4 BGP peering 174 source address to be used by the receiver. At least one of IPv4 or 175 IPv6 BGP source addresses MUST be announced. 177 As usual, the BGP OPEN capability negotiation will determine the AFI/ 178 SAFIs to be transported over the peering, see [RFC4760] . 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Attr Type = 2 | Attr Len = 56 | My IPv4 Peering Address ~ 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 ~ | Prefix Len | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 3.1.3. BGP IPv6 Address 190 The BGP IPv6 Address sub-TLV announces the sender's IPv6 BGP peering 191 source address to be used by the receiver. At least one of IPv4 or 192 IPv6 BGP source addresses MUST be announced. 194 As usual, the BGP OPEN capability negotiation will determine the AFI/ 195 SAFIs to be transported over the peering, see [RFC4760] . 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Attr Type = 3 | Attr Len = 152| | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 202 | | 203 + + 204 | My IPv6 Peering Address | 205 + + 206 | | 207 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | Prefix Len | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 3.1.4. BGP Authentication sub-TLV 213 The BGP Authentication sub-TLV provides any authentication data 214 needed to OPEN the BGP session. Depending on operator configuration 215 of the environment, it might be a simple MD5 key (see [RFC2385]), the 216 name of a key chain a KARP database (see [RFC7210]), or one of 217 multiple Authentication sub-TLVs to support hop[RFC4808]. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Attr Type = 4 | Attr Len | ~ 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 224 ~ BGP Authentication Data ... ~ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 3.1.5. BGP Miscellaneous Flags 229 The BGP session OPEN has extensive, and a bit complex, capability 230 negotiation facilities. In case one or more extra attributes might 231 be needed, the BGP Miscellaneous Flags sub-TLV may be used. No flags 232 are currently defined. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Attr Type = 5 | Attr Len = 32 | Misc Flags | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Misc Attrs: 242 Bit 0: Ghu knows what 243 Bit 1-15: Must be zero 245 4. Security Considerations 247 All the Security considerations of [I-D.ietf-lsvr-l3dl] apply to this 248 PDU. 250 As the ULPC PDU may contain keying material, see Section 3.1.4, it 251 SHOULD BE signed. 253 Any keying material in the PDU SHOULD BE salted ad hashed. 255 The BGP Authentication sub-TLV provides for provisioning MD5, which 256 is a quite weak hash, horribly out of fashion, and kills puppies. 257 But, like it or not, it is what BGP deployments use. 259 5. IANA Considerations 261 This document requests the IANA create a new entry in the L3DL PDU 262 Type registry as follows: 264 PDU 265 Code PDU Name 266 ---- ------------------- 267 9 ULPC 269 This document requests the IANA create a registry for L3DL ULPC Type, 270 which may range from 0 to 255. The name of the registry should be 271 L3DL-ULPC-Type. The policy for adding to the registry is RFC 272 Required per [RFC5226], either standards track or experimental. The 273 initial entries should be the following: 275 Bit Bit Name 276 ---- ------------------- 277 0 Reserved 278 1 BGP 279 2-255 Reserved 281 6. References 283 6.1. Normative References 285 [I-D.ietf-lsvr-l3dl] 286 Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery 287 and Liveness", draft-ietf-lsvr-l3dl-00 (work in progress), 288 April 2019. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 296 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 297 DOI 10.17487/RFC4271, January 2006, 298 . 300 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 301 "Multiprotocol Extensions for BGP-4", RFC 4760, 302 DOI 10.17487/RFC4760, January 2007, 303 . 305 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 306 IANA Considerations Section in RFCs", RFC 5226, 307 DOI 10.17487/RFC5226, May 2008, 308 . 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 6.2. Informative References 316 [I-D.ietf-lsvr-bgp-spf] 317 Patel, K., Lindem, A., Zandi, S., and W. Henderickx, 318 "Shortest Path Routing Extensions for BGP Protocol", 319 draft-ietf-lsvr-bgp-spf-04 (work in progress), December 320 2018. 322 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 323 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 324 1998, . 326 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 327 RFC 4808, DOI 10.17487/RFC4808, March 2007, 328 . 330 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 331 "Database of Long-Lived Symmetric Cryptographic Keys", 332 RFC 7210, DOI 10.17487/RFC7210, April 2014, 333 . 335 Authors' Addresses 337 Randy Bush 338 Arrcus & IIJ 339 5147 Crystal Springs 340 Bainbridge Island, WA 98110 341 United States of America 343 Email: randy@psg.com 345 Keyur Patel 346 Arrcus 347 2077 Gateway Place, Suite #400 348 San Jose, CA 95119 349 United States of America 351 Email: keyur@arrcus.com