idnits 2.17.1 draft-white-bgpbgp-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2014) is 3601 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) == Missing Reference: 'TBD' is mentioned on line 120, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-05 == Outdated reference: A later version (-13) exists of draft-ietf-idr-sla-exchange-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track R. White 5 Expires: December 18, 2014 J. Heitz 6 Ericsson 7 June 16, 2014 9 BGP Based Generic TransPort (bgpBGP) 10 draft-white-bgpbgp-00 12 Abstract 14 A wide array of information is being carried (or proposed to be 15 carried) through BGP peering sessions. While this information is 16 necessary and valid, BGP was not designed to carry blobs of 17 information, but rather network layer reachability and information 18 related directly to forwarding traffic from peer to peer. This 19 document proposes a new BGP message type with a well defined 20 structure to use BGP peering sessions for information passed from 21 provider to provider along edge peering points, the BGP based Generic 22 transPort (bgpBGP). This message type is designed to allow any pair 23 of BGP speakers to transfer information within an existing session, 24 or for BGP peering semantics to be used with multihop sessions 25 between "information exchange speakers" within an autonomous system. 26 The new message type is designed to provide flexibility by allowing 27 the encoding of virtually any information within a BGP session 28 through the use of type-length-vector formatting. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 18, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 65 2. Description of the Problem Space . . . . . . . . . . . . . . 2 66 3. The Generic Transport Message . . . . . . . . . . . . . . . . 3 67 4. Negotiating BGP Based Generic Transport . . . . . . . . . . . 6 68 5. Peer Restart/Database Refresh . . . . . . . . . . . . . . . . 6 69 6. The Generic Transport Database Descriptor and Request . . . . 7 70 7. The Certificate Generic Transport Block . . . . . . . . . . . 8 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 10.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Description of the Problem Space 86 In many ways, BGP has become the "default pigeon carrier" of the 87 Internet. In order to carry routing information, two autonomous 88 systems must already have functioning BGP peering sessions 89 configured, and BGP itself is easily extensible through address 90 families, extended communities, and other mechanisms. The existence 91 of working connections and easy extensibility, however, creates a 92 situation where BGP is being asked to carry data that reaches far 93 beyond network layer reachability information. For instance, Inter- 94 Domain SLA Exchange [I-D.ietf-idr-sla-exchange] provides a mechanism 95 whereby service level information can be exchanged through a BGP 96 peering session between speakers located in different autonomous 97 systems. Another example is North-Bound Distribution of Link-State 98 and TE Information using BGP [I-D.ietf-idr-ls-distribution], which 99 distributes link state information through a special encoding through 100 BGP. 102 Both of these use cases, and many others, such as transporting X.509 103 certificates, could be served better by carrying information outside 104 the standard NLRI formatting of BGP. This draft defines a new 105 message type that would applications to carry information through a 106 BGP session by encoding them in a new message type, rather than 107 embedding them in what appears to be standard BGP routing 108 information. [RFC4721] This new message type is configured between 109 two peers through a standard capabilities exchange process, and 110 carries type-length-vector encoded data. 112 Two uses for BGP Generic Transport are described in this document: 113 carrying X.509 certificates and a generic transport database 114 description. These use cases provide justification and the needed 115 framework within which to place this new message type. 117 3. The Generic Transport Message 119 The Generic Transport Message (GTM) header is formatted as described 120 in BGP [RFC4721] section 4, with a type code of [TBD]. Within the 121 GTM message is a series of TLVs, Generic Transport Blocks (GTBs), 122 formatted as: 124 0 1 2 3 125 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 126 +-------------------------------+-------------------------------+ 127 | Type | Length | 128 +-------------------------------+-------------------------------+ 129 | Identifier | 130 | | 131 | | 132 | | 133 +---------------------------------------------------------------+ 134 | Sequence | 135 | | 136 | | 137 | | 138 +---------------------------------------------------------------+ 139 | Extended Community Header | 140 | | 141 +---------------------------------------------------------------+ 142 | Data ... 143 +----------------------------- 145 The fields above are: 147 o Type: A two octet unsigned integer describing the GTB type 149 o Length: A two octet unsigned integer describing the length of the 150 GTB in octets 152 o Identifier: A sixteen octet field which can be used by the 153 application to uniquely identify the information carried in this 154 GTB 156 o Sequence: A sixteen octet field which can be used by the 157 application to indicate the relative ordering of information of 158 the same type and identity carried in this GTB 160 o Extended Community Header: An eight octet field formatted as 161 described in [RFC4360] 163 o Data: The data, as described in the specific GTB format 165 GTB types SHOULD be set to a code allocated by IANA for any GTB 166 format which passes through the IETF process (including experimental 167 or individual contribution). Experimental GTB type codes are 168 intended for local experimental use when developing applications 169 using GTB to transfer data through a BGP session, or applications 170 using this technique wholly within a single administrative domain. 172 The identifier can be used by the application to indicate some unique 173 property of the information carried in the data field. This allows 174 the BGP speaker to determine if this information is unique, or 175 information already contained in a local database. 177 The sequence field can be used by the application to indicate the 178 "freshness" of the information carried in the data field. The most 179 obvious use of this field would be a monotonically increasing number 180 indicating a newer version of some information advertised previously. 182 The extended community header is intended to allow for the use of 183 extended communities to control the distribution of the data included 184 in this GTB through route targets or other means. BGP speakers MUST 185 control the flooding, distribution, and processing of the GTB as 186 indicated in the information carried in this field. 188 Processing received GTBs will proceed as follows: 190 o If a route target, community value, or other field in the extended 191 community header indicates the GTB should not be accepted by the 192 local router (through inbound filtering), the GTB is silently 193 discarded 195 o If the type and identifier fields do not match any locally stored 196 GTB, the received GTB is silently discarded 198 o If the type, identifier, and sequence fields match a GTB stored 199 locally, follow the matching id/sequence number procedure outlined 200 below 202 o If the type and identifier fields match a GTB stored locally, and 203 the sequence number is less than the sequence number of the 204 locally stored GTB, the received GTB is silently discarded 206 o If the type and identifier fields match a GTB stored locally, and 207 the sequence number is set to 0, follow the withdraw procedure 208 outlined below 210 o If the type and identifier fields match, and the sequence number 211 is higher than the sequence number of the locally stored GTB, 212 follow the update procedure outlined below 214 Matching ID/Sequence procedure: 216 o If the remainder of the GTB matches an existing GTB, silently 217 discard the received GTB 219 o If the remained of the GTB does not match an existing GTB, log an 220 error and discard the received GTB 222 Withdraw procedure: 224 o The received GTB with a sequence number set to 0 is forwarded to 225 all peers 227 o The GTB is removed from local storage 229 Update procedure: 231 o The received GTB is forward to all peers, limited by the route 232 target or other filtering options indicated in the extended 233 community header 235 o The received GTB replaces the existing GTB in local storage 237 4. Negotiating BGP Based Generic Transport 239 The BGP Based Generic Transport Capability is a new BGP capability 240 [RFC5492]. The Capability Code for this capability is specified in 241 the IANA Considerations section of this document. The Capability 242 Length field of this capability is 0. 244 By advertising the BGP Based Generic Transport Capability to a peer, 245 a BGP speaker conveys to the peer that the speaker is capable of 246 receiving and properly handling BGP Based Generic Transport messages. 248 5. Peer Restart/Database Refresh 250 In certain situations, one speaker in a peering session may restarted 251 (as outlined in [RFC4724]), a local filtering change may require 252 reprocessing of the entire GTB database (or some subset, similar to 253 the situation outlined in [RFC2918]), or the GTB database may need to 254 be refreshed for some other reason. While route refresh and graceful 255 restart assume BGP has some knowledge of the information being 256 exchanged between peers, BGP generic transport assumes BGP is 257 carrying essentially opaque data. Therefore the procedure relies on 258 a database description and database request process, rather than end 259 of table markers, as follows: 261 Restarting speakers MAY hold a copy of the GTB database in 262 nonvolatile storage to protect information carried through GTB 263 across restarts. If a local copy of the GTBs is available when a 264 resynchronization begins, the originating speaker MUST mark the 265 existing entries as "dirty," so nonexistent entries can be removed 266 at the end of the resynchronization process. 268 The speaker which wishes to resynchronize (either due to a 269 restart, change in filtering policy, or for any other reason), 270 sends its peer a Database Descriptor (GTBDD) Request with the type 271 field set to 0x01, the sequence number set to 0x0, and the 272 identifier set to the local router id. Future GTBDDs will have a 273 monotonically increasing sequence number. 275 The speaker receiving this request will format a series of GTBDDs 276 (type 0x02), describing the local database of GTBs, as described 277 below. These descriptor lists carry the type, identifier, and 278 sequence number of each GTB in the sender's database. The sending 279 speaker ends the list with a GTBDD type 0x04, which indicates the 280 entire database has been transmitted. 282 The resynchronizing speaker compares this list of GTBs to local 283 storage. For each GTB, the resynchronizing speaker determines if 284 it has an up to date local copy of the GTB, or not. For GTBs with 285 a matching local copy, the "dirty" marker set above MUST be 286 cleared. 288 The resynchronizing speaker sends a GTBDD request (type 0x03) for 289 each GTB which it is missing in its local storage, finishing with 290 a GTBDD end of database marker (type 0x04). 292 The speaker receiving this request will transmit the requested 293 GTBs, which will be processed according to normal rules (as 294 outlined above). 296 At the end of processing, all GTBs which were marked as "dirty" 297 MUST be removed from the local database. 299 6. The Generic Transport Database Descriptor and Request 301 The generic transport database descriptor can be used to describe the 302 current state of the local GTB database in a BGP speaker. For this 303 GTP, the following fields will be used: 305 o For a database descriptor request, the type field will be set to 306 0x01 308 o For a database description listing, the type field will be set to 309 0x02 311 o For a GTB request, the type field will be set to 0x03 313 o For an end of database marker, the type field will be set to 0x04 314 o The length field will be set to the length of the database 315 descriptor 317 o The I bit will be set indicating this is an IANA defined type code 319 o The T bit will be clear indicating this is a non-transitive GTB 321 o The identifier field will be set to router ID of the BGP speaker 322 sending the GTB 324 o The sequence number will be set to a monotonically increasing 325 number set by the originator indicating the block of entry 326 descriptors in the current GTB 328 The data field will consist of a list of GTB headers. If this GTB is 329 a descriptor, these GTB headers will be taken as a list of GTBs 330 contained in the local database of the transmitter. If this GTB is a 331 request, these GTB headers will be taken as a list of GTBs the 332 speaker would like the receiver to transmit to the originator of the 333 GTB. 335 7. The Certificate Generic Transport Block 337 The certificate GTP carries a Route Origin Authentication (ROA) X.509 338 certificate as described in [RFC6482]. For this GTP, the following 339 fields will be used: 341 o The type field will be set to 0x05 343 o The length field will be set to the length of the ROA 345 o The I bit within the extended community header will be set 346 indicating this is an IANA defined type code 348 o The T bit within the extended community header will be set 349 indicating this is a transitive GTB 351 o The identifier field will be set to the prefix contained in the 352 ROA 354 o The sequence number will be set to the expiration time of the 355 certificate, encoded as described in [RFC6482] 357 8. IANA Considerations 359 This document introduces the BGP Based Generic Transport Capability. 360 The capability code needs to be assigned by IANA per [RFC5492]. 362 This document introduces a new BGP message type, BGPBGP. The type 363 code needs to be assigned by IANA. 365 This document introduces a new GTB type for describing the type and 366 format of information carried in a GTB TLV within a GTM. This is a 367 new 32 bit number space that needs to be registered with the IANA. 369 9. Security Considerations 371 None. 373 10. References 375 10.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 381 September 2000. 383 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 384 Communities Attribute", RFC 4360, February 2006. 386 [RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 387 Challenge/Response Extensions (Revised)", RFC 4721, 388 January 2007. 390 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 391 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 392 January 2007. 394 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 395 with BGP-4", RFC 5492, February 2009. 397 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 398 Origin Authorizations (ROAs)", RFC 6482, February 2012. 400 10.2. Informative References 402 [I-D.ietf-idr-ls-distribution] 403 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 404 Ray, "North-Bound Distribution of Link-State and TE 405 Information using BGP", draft-ietf-idr-ls-distribution-05 406 (work in progress), May 2014. 408 [I-D.ietf-idr-sla-exchange] 409 Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. 410 Boucadair, "Inter-domain SLA Exchange", draft-ietf-idr- 411 sla-exchange-03 (work in progress), April 2014. 413 Authors' Addresses 415 Alvaro Retana 416 Cisco Systems, Inc. 417 7025 Kit Creek Rd. 418 Research Triangle Park, NC 27709 419 USA 421 Email: aretana@cisco.com 423 Russ White 424 Ericsson 426 Email: russw@riw.us 428 Jakob Heitz 429 Ericsson 431 Email: jakob.heitz@ericsson.com