idnits 2.17.1 draft-ietf-grow-bmp-17.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 13, 2016) is 3026 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Scudder, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Fernando 5 Expires: July 16, 2016 Cisco Systems 6 S. Stuart 7 Google 8 January 13, 2016 10 BGP Monitoring Protocol 11 draft-ietf-grow-bmp-17 13 Abstract 15 This document defines a protocol, BMP, that can be used to monitor 16 BGP sessions. BMP is intended to provide a convenient interface for 17 obtaining route views. Prior to introduction of BMP, screen-scraping 18 was the most commonly-used approach to obtaining such views. The 19 design goals are to keep BMP simple, useful, easily implemented, and 20 minimally service-affecting. BMP is not suitable for use as a 21 routing protocol. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 16, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Overview of BMP Operation . . . . . . . . . . . . . . . . . . 4 73 3.1. BMP Messages . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Connection Establishment and Termination . . . . . . . . 4 75 3.3. Lifecycle of a BMP Session . . . . . . . . . . . . . . . 5 76 4. BMP Message Format . . . . . . . . . . . . . . . . . . . . . 6 77 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 6 78 4.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 7 79 4.3. Initiation Message . . . . . . . . . . . . . . . . . . . 9 80 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9 81 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10 82 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11 83 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11 84 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12 85 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14 86 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 87 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 88 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 89 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 91 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 92 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 93 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 96 10.2. BMP Peer Types . . . . . . . . . . . . . . . . . . . . . 20 97 10.3. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 20 98 10.4. BMP Statistics Types . . . . . . . . . . . . . . . . . . 21 99 10.5. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 100 10.6. BMP Termination Message TLVs . . . . . . . . . . . . . . 22 101 10.7. BMP Termination Message Reason Codes . . . . . . . . . . 22 102 10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 103 10.9. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 23 104 10.10. BMP Route Mirroring Information Codes . . . . . . . . . 23 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 106 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 109 13.2. Informative References . . . . . . . . . . . . . . . . . 25 110 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25 111 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 114 1. Introduction 116 Many researchers and network operators wish to have access to the 117 contents of routers' BGP RIBs as well as a view of protocol updates 118 the router is receiving. This monitoring task cannot be realized by 119 standard protocol mechanisms. Prior to introduction of BMP, this 120 data could only be obtained through screen-scraping. 122 The BMP protocol provides access to the Adj-RIB-In of a peer on an 123 ongoing basis and a periodic dump of certain statistics the 124 monitoring station can use for further analysis. From a high level, 125 BMP can be thought of as the result of multiplexing together the 126 messages received on the various monitored BGP sessions. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in RFC 133 2119 [RFC2119]. 135 2. Definitions 137 o Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains 138 unprocessed routing information that has been advertised to the 139 local BGP speaker by its peers." This is also referred to as the 140 pre-policy Adj-RIB-In in this document. 142 o Post-Policy Adj-RIB-In: The result of applying inbound policy to 143 an Adj-RIB-In, but prior to the application of route selection to 144 form the Loc-RIB. 146 3. Overview of BMP Operation 148 3.1. BMP Messages 150 The following are the messages provided by BMP. 152 o Route Monitoring (RM): Used to provide an initial dump of all 153 routes received from a peer as well as an ongoing mechanism that 154 sends the incremental routes advertised and withdrawn by a peer to 155 the monitoring station. 157 o Peer Down Notification: A message sent to indicate a peering 158 session has gone down with information indicating the reason for 159 the session disconnect. 161 o Stats Reports (SR): An ongoing dump of statistics that can be used 162 by the monitoring station as a high level indication of the 163 activity going on in the router. 165 o Peer Up Notification: A message sent to indicate a peering session 166 has come up. The message includes information regarding the data 167 exchanged between the peers in their OPEN messages as well as 168 information about the peering TCP session itself. In addition to 169 being sent whenever a peer transitions to ESTABLISHED state, a 170 Peer Up Notification is sent for each peer in ESTABLISHED state 171 when the BMP session itself comes up. 173 o Initiation: A means for the monitored router to inform the 174 monitoring station of its vendor, software version, and so on. 176 o Termination: A means for the monitored router to inform the 177 monitoring station of why it is closing a BMP session. 179 o Route Mirroring: a means for the monitored router to send verbatim 180 duplicates of messages as received. Can be used to exactly mirror 181 a monitored BGP session. Can also be used to report malformed BGP 182 PDUs. 184 3.2. Connection Establishment and Termination 186 BMP operates over TCP. All options are controlled by configuration 187 on the monitored router. No BMP message is ever sent from the 188 monitoring station to the monitored router. The monitored router MAY 189 take steps to prevent the monitoring station from sending data (for 190 example by half-closing the TCP session or setting its window size to 191 zero) or it MAY silently discard any data sent by the monitoring 192 station. 194 The router may be monitored by one or more monitoring stations. With 195 respect to each (router, monitoring station) pair, one party is 196 active with respect to TCP session establishment, and the other party 197 is passive. Which party is active and which is passive is controlled 198 by configuration. 200 The passive party is configured to listen on a particular TCP port 201 and the active party is configured to establish a connection to that 202 port. If the active party is unable to connect to the passive party, 203 it periodically retries the connection. Retries MUST be subject to 204 some variety of backoff. Exponential backoff with a default initial 205 backoff of 30 seconds and a maximum of 720 seconds is suggested. 207 The router MAY restrict the set of IP addresses from which it will 208 accept connections. It SHOULD restrict the number of simultaneous 209 connections it will permit from a given IP address. The default 210 value for this restriction SHOULD be 1, though an implementation MAY 211 permit this restriction to be disabled in configuration. The router 212 MUST also restrict the rate at which sessions may be established. A 213 suggested default is an establishment rate of 2 sessions per minute. 215 A router (or management station) MAY implement logic to detect 216 redundant connections, as might occur if both parties are configured 217 to be active, and MAY elect to terminate redundant connections. A 218 Termination reason code is defined for this purpose. 220 Once a connection is established, the router sends messages over it. 221 There is no initialization or handshaking phase, messages are simply 222 sent as soon as the connection is established. 224 If the monitoring station intends to end or restart BMP processing, 225 it simply drops the connection. 227 3.3. Lifecycle of a BMP Session 229 A router is configured to speak BMP to one or more monitoring 230 stations. It MAY be configured to send monitoring information for 231 only a subset of its BGP peers. Otherwise, all BGP peers are assumed 232 to be monitored. 234 A BMP session begins when the active party (either router or 235 management station, as determined by configuration) successfully 236 opens a TCP session (the "BMP session"). Once the session is up, the 237 router begins to send BMP messages. It MUST begin by sending an 238 Initiation message. It subsequently sends a Peer Up message over the 239 BMP session for each of its monitored BGP peers that is in 240 Established state. It follows by sending the contents of its Adj- 241 RIBs-In (pre-policy, post-policy or both, see Section 5) encapsulated 242 in Route Monitoring messages. Once it has sent all the routes for a 243 given peer, it MUST send a End-of-RIB message for that peer; when 244 End-of-RIB has been sent for each monitored peer, the initial table 245 dump has completed. (A monitoring station that wishes only to gather 246 a table dump could close the connection once it has gathered an End- 247 of-RIB or Peer Down message corresponding to each Peer Up message.) 249 Following the initial table dump, the router sends incremental 250 updates encapsulated in Route Monitoring messages. It MAY 251 periodically send Stats Reports or even new Initiation messages, 252 according to configuration. If any new monitored BGP peer becomes 253 Established, a corresponding Peer Up message is sent. If any BGP 254 peers for which Peer Up messages were sent transition out of the 255 Established state, corresponding Peer Down messages are sent. 257 A BMP session ends when the TCP session that carries it is closed for 258 any reason. The router MAY send a Termination message prior to 259 closing the session. 261 4. BMP Message Format 263 4.1. Common Header 265 The following common header appears in all BMP messages. The rest of 266 the data in a BMP message is dependent on the "Message Type" field in 267 the common header. 269 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 270 +-+-+-+-+-+-+-+-+ 271 | Version | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Message Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Msg. Type | 276 +---------------+ 278 o Version (1 byte): Indicates the BMP version. This is set to '3' 279 for all messages defined in this specification. Version 0 is 280 reserved and MUST NOT be sent. 282 o Message Length (4 bytes): Length of the message in bytes 283 (including headers, data and encapsulated messages, if any). 285 o Message Type (1 byte): This identifies the type of the BMP 286 message. A BMP implementation MUST ignore unrecognized message 287 types upon receipt. 289 * Type = 0: Route Monitoring 290 * Type = 1: Statistics Report 291 * Type = 2: Peer Down Notification 292 * Type = 3: Peer Up Notification 293 * Type = 4: Initiation Message 294 * Type = 5: Termination Message 295 * Type = 6: Route Mirroring Message 297 4.2. Per-Peer Header 299 The per-peer header follows the common header for most BMP messages. 300 The rest of the data in a BMP message is dependent on the "Message 301 Type" field in the common header. 303 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Peer Type | Peer Flags | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Peer Distinguisher (present based on peer type) | 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Peer Address (16 bytes) | 311 ~ ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Peer AS | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Peer BGP ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Timestamp (seconds) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Timestamp (microseconds) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 o Peer Type (1 byte): Identifies the type of the peer. Currently 323 two types of peers are identified, 325 * Peer Type = 0: Global Instance Peer 326 * Peer Type = 1: RD Instance Peer 327 * Peer Type = 2: Local Instance Peer 329 o Peer Flags (1 byte): These flags provide more information about 330 the peer. The flags are defined as follows. 332 0 1 2 3 4 5 6 7 8 333 +-+-+-+-+-+-+-+-+ 334 |V|L|A| Reserved| 335 +-+-+-+-+-+-+-+-+ 337 * The V flag indicates the the Peer address is an IPv6 address. 338 For IPv4 peers this is set to 0. 339 * The L flag, if set to 1, indicates the message reflects the 340 post-policy Adj-RIB-In (i.e., its path attributes reflect the 341 application of inbound policy). It is set to 0 if the message 342 reflects the pre-policy Adj-RIB-In. Locally-sourced routes 343 also carry an L flag of 1. See Section 5 for further detail. 344 This flag has no significance when used with route mirroring 345 messages (Section 4.7). 346 * The A flag, if set to 1, indicates the message is formatted 347 using the legacy two-byte AS_PATH format. If set to 0, the 348 message is formatted using the four-byte AS_PATH format 349 [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH 350 information as received from its peer, or it MAY choose to 351 reformat all AS_PATH information into four-byte format 352 regardless of how it was received from the peer. In the latter 353 case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be 354 sent in the BMP UPDATE message. This flag has no significance 355 when used with route mirroring messages (Section 4.7). 356 * The remaining bits are reserved for future use. They MUST be 357 transmitted as zero and their values MUST be ignored on 358 receipt. 360 o Peer Distinguisher (8 bytes): Routers today can have multiple 361 instances (example: L3VPNs [RFC4364]). This field is present to 362 distinguish peers that belong to one address domain from the 363 other. 365 If the peer is a "Global Instance Peer", this field is zero 366 filled. If the peer is a "RD Instance Peer", it is set to the 367 route distinguisher of the particular instance the peer belongs 368 to. If the peer is a "Local Instance Peer", it is set to a 369 unique, locally-defined value. In all cases, the effect is that 370 the combination of the Peer Type and Peer Distinguisher is 371 sufficient to disambiguate peers for which other identifying 372 information might overlap. 374 o Peer Address: The remote IP address associated with the TCP 375 session over which the encapsulated PDU was received. It is 4 376 bytes long if an IPv4 address is carried in this field (with the 377 12 most significant bytes zero-filled) and 16 bytes long if an 378 IPv6 address is carried in this field. 380 o Peer AS: The Autonomous System number of the peer from which the 381 encapsulated PDU was received. If a 16 bit AS number is stored in 382 this field [RFC6793], it should be padded with zeroes in the 16 383 most significant bits. 385 o Peer BGP ID: The BGP Identifier of the peer from which the 386 encapsulated PDU was received. 388 o Timestamp: The time when the encapsulated routes were received 389 (one may also think of this as the time when they were installed 390 in the Adj-RIB-In), expressed in seconds and microseconds since 391 midnight (zero hour), January 1, 1970 (UTC). If zero, the time is 392 unavailable. Precision of the timestamp is implementation- 393 dependent. 395 4.3. Initiation Message 397 The initiation message provides a means for the monitored router to 398 inform the monitoring station of its vendor, software version, and so 399 on. An initiation message MUST be sent as the first message after 400 the TCP session comes up. An initiation message MAY be sent at any 401 point thereafter, if warranted by a change on the monitored router. 403 The initiation message consists of the common BMP header followed by 404 two or more Information TLVs (Section 4.4) containing information 405 about the monitored router. The sysDescr and sysName Information 406 TLVs MUST be sent, any others are optional. The string TLV MAY be 407 included multiple times. 409 4.4. Information TLV 411 The Information TLV is used by the Initiation (Section 4.3) and Peer 412 Up (Section 4.10) messages. 414 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Information Type | Information Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Information (variable) | 419 ~ ~ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 o Information Type (2 bytes): Type of information provided. Defined 423 types are: 425 * Type = 0: String. The Information field contains a free-form 426 UTF-8 string whose length is given by the "Information Length" 427 field. The value is administratively assigned. There is no 428 requirement to terminate the string with a null (or any other 429 particular) character -- the length field gives its 430 termination. If multiple strings are included, their ordering 431 MUST be preserved when they are reported. 433 * Type = 1: sysDescr. The Information field contains an ASCII 434 string whose value MUST be set to be equal to the value of the 435 sysDescr MIB-II [RFC1213] object. 437 * Type = 2: sysName. The Information field contains a ASCII 438 string whose value MUST be set to be equal to the value of the 439 sysName MIB-II [RFC1213] object. 441 o Information Length (2 bytes): The length of the following 442 Information field, in bytes. 444 o Information (variable): Information about the monitored router, 445 according to the type. 447 4.5. Termination Message 449 The termination message provides a way for a monitored router to 450 indicate why it is terminating a session. Although use of this 451 message is RECOMMENDED, a monitoring station must always be prepared 452 for the session to terminate with no message. Once the router has 453 sent a termination message, it MUST close the TCP session without 454 sending any further messages. Likewise, the monitoring station MUST 455 close the TCP session after receiving a termination message. 457 The termination message consists of the common BMP header followed by 458 one or more TLVs containing information about the reason for the 459 termination, as follows: 461 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Information Type | Information Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Information (variable) | 466 ~ ~ 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 o Information Type (2 bytes): Type of information provided. Defined 470 types are: 472 * Type = 0: String. The Information field contains a free-form 473 UTF-8 string whose length is given by the "Information Length" 474 field. Inclusion of this TLV is optional. It MAY be used to 475 provide further detail for any of the defined reasons. 476 Multiple String TLVs MAY be included in the message. 478 * Type = 1: Reason. The Information field contains a two-byte 479 code indicating the reason the connection was terminated. Some 480 reasons may have further TLVs associated with them. Inclusion 481 of this TLV is REQUIRED. Defined reasons are: 483 + Reason = 0: Session administratively closed. The session 484 might be re-initiated. 486 + Reason = 1: Unspecified reason. 488 + Reason = 2: Out of resources. The router has exhausted 489 resources available for the BMP session. 491 + Reason = 3: Redundant connection. The router has determined 492 this connection is redundant with another one. 494 + Reason = 4: Session permanently administratively closed, 495 will not be re-initiated. Monitoring station should reduce 496 (potentially to zero) the rate at which it attempts 497 reconnection to the monitored router. 499 o Information Length (2 bytes): The length of the following 500 Information field, in bytes. 502 o Information (variable): Information about the monitored router, 503 according to the type. 505 4.6. Route Monitoring 507 Route Monitoring messages are used for initial synchronization of 508 ADJ-RIBs-In. They are also used for ongoing monitoring of ADJ-RIB-In 509 state. Route monitoring messages are state-compressed. This is all 510 discussed in more detail in Section 5. 512 Following the common BMP header and per-peer header is a BGP Update 513 PDU. 515 4.7. Route Mirroring 517 Route Mirroring messages are used for verbatim duplication of 518 messages as received. A possible use for mirroring is exact 519 mirroring of one or more monitored BGP sessions, without state 520 compression. Another possible use is mirroring of messages that have 521 been treated-as-withdraw [RFC7606], for debugging purposes. Mirrored 522 messages may be sampled, or may be lossless. The Messages Lost 523 Information code is provided to allow losses to be indicated. 524 Section 6 provides more detail. 526 Following the common BMP header and per-peer header is a set of TLVs 527 that contain information about a message or set of messages. Each 528 TLV comprises a two-byte type code, a two-byte length field, and a 529 variable-length value. Inclusion of any given TLV is OPTIONAL, 530 however at least one TLV SHOULD be included, otherwise what's the 531 point of sending the message? Defined TLVs are as follows: 533 o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an 534 Update message. If the BGP Message TLV occurs in the Route 535 Mirroring message, it MUST occur last in the list of TLVs. 537 o Type = 1: Information. A two-byte code that provides information 538 about the mirrored message or message stream. Defined codes are: 540 * Code = 0: Errored PDU. The contained message was found to have 541 some error that made it unusable, causing it to be treated-as- 542 withdraw [RFC7606]. A BGP Message TLV MUST also occur in the 543 TLV list. 545 * Code = 1: Messages Lost. One or more messages may have been 546 lost. This could occur, for example, if an implementation runs 547 out of available buffer space to queue mirroring messages. 549 A Route Mirroring message may be sent any time it would be legal to 550 send a Route Monitoring message. 552 4.8. Stats Reports 554 These messages contain information that could be used by the 555 monitoring station to observe interesting events that occur on the 556 router. 558 Transmission of SR messages could be timer triggered or event driven 559 (for example, when a significant event occurs or a threshold is 560 reached). This specification does not impose any timing restrictions 561 on when and on what event these reports have to be transmitted. It 562 is left to the implementation to determine transmission timings -- 563 however, configuration control should be provided of the timer and/or 564 threshold values. This document only specifies the form and content 565 of SR messages. 567 Following the common BMP header and per-peer header is a 4-byte field 568 that indicates the number of counters in the stats message where each 569 counter is encoded as a TLV. 571 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Stats Count | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Each counter is encoded as follows, 578 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Stat Type | Stat Len | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Stat Data | 583 ~ ~ 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 o Stat Type (2 bytes): Defines the type of the statistic carried in 587 the "Stat Data" field. 589 o Stat Len (2 bytes): Defines the length of the "Stat Data" Field. 591 This specification defines the following statistics. A BMP 592 implementation MUST ignore unrecognized stat types on receipt, and 593 likewise MUST ignore unexpected data in the Stat Data field. 595 Stats are either counters or gauges, defined as follows after the 596 examples of [RFC1155] Section 3.2.3.3 and [RFC2856] Section 4 597 respectively: 599 32-bit Counter: A non-negative integer which monotonically increases 600 until it reaches a maximum value, when it wraps around and starts 601 increasing again from zero. It has a maximum value of 2^32-1 602 (4294967295 decimal). 604 64-bit Gauge: non-negative integer, which may increase or decrease, 605 but shall never exceed a maximum value, nor fall below a minimum 606 value. The maximum value can not be greater than 2^64-1 607 (18446744073709551615 decimal), and the minimum value can not be 608 smaller than 0. The value has its maximum value whenever the 609 information being modeled is greater than or equal to its maximum 610 value, and has its minimum value whenever the information being 611 modeled is smaller than or equal to its minimum value. If the 612 information being modeled subsequently decreases below (increases 613 above) the maximum (minimum) value, the 64-bit Gauge also decreases 614 (increases). 616 o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by 617 inbound policy. 619 o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix 620 advertisements. 622 o Stat Type = 2: (32-bit Counter) Number of (known) duplicate 623 withdraws. 625 o Stat Type = 3: (32-bit Counter) Number of updates invalidated due 626 to CLUSTER_LIST loop. 628 o Stat Type = 4: (32-bit Counter) Number of updates invalidated due 629 to AS_PATH loop. 631 o Stat Type = 5: (32-bit Counter) Number of updates invalidated due 632 to ORIGINATOR_ID. 634 o Stat Type = 6: (32-bit Counter) Number of updates invalidated due 635 to AS_CONFED loop. 637 o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In. 639 o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. 641 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The 642 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 643 a 64-bit Gauge. 645 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The 646 value is structured as: AFI (2 bytes), SAFI (1 byte), followed by 647 a 64-bit Gauge. 649 o Stat Type = 11: (32-bit Counter) Number of updates subjected to 650 treat-as-withdraw treatment [RFC7606]. 652 o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to 653 treat-as-withdraw treatment [RFC7606]. 655 o Stat Type = 13: (32-bit Counter) Number of duplicate update 656 messages received. 658 Although the current specification only specifies 4-byte counters and 659 8-byte gauges as "Stat Data", this does not preclude future versions 660 from incorporating more complex TLV-type "Stat Data" (for example, 661 one that can carry prefix specific data). SR messages are optional. 662 However if an SR message is transmitted, at least one statistic MUST 663 be carried in it. 665 4.9. Peer Down Notification 667 This message is used to indicate a peering session was terminated. 669 0 1 2 3 4 5 6 7 8 670 +-+-+-+-+-+-+-+-+ 671 | Reason | 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Data (present if Reason = 1, 2 or 3) | 674 ~ ~ 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Reason indicates why the session was closed. Defined values are: 679 o Reason 1: The local system closed the session. Following the 680 Reason is a BGP PDU containing a BGP NOTIFICATION message that 681 would have been sent to the peer. 683 o Reason 2: The local system closed the session. No notification 684 message was sent. Following the reason code is a two-byte field 685 containing the code corresponding to the FSM Event that caused the 686 system to close the session (see Section 8.1 of [RFC4271]). Two 687 bytes both set to zero are used to indicate no relevant Event code 688 is defined. 690 o Reason 3: The remote system closed the session with a notification 691 message. Following the Reason is a BGP PDU containing the BGP 692 NOTIFICATION message as received from the peer. 694 o Reason 4: The remote system closed the session without a 695 notification message. This includes any unexpected termination of 696 the transport session, so in some cases both the local and remote 697 systems might consider this to apply. 699 o Reason 5: Information for this peer will no longer be sent to the 700 monitoring station for configuration reasons. This does not, 701 strictly speaking, indicate the peer has gone down, but it does 702 indicate the monitoring station will not receive updates for the 703 peer. 705 A Peer Down message implicitly withdraws all routes that had been 706 associated with the peer in question. A BMP implementation MAY omit 707 sending explicit withdraws for such routes. 709 4.10. Peer Up Notification 711 The Peer Up message is used to indicate a peering session has come up 712 (i.e., has transitioned into ESTABLISHED state). Following the 713 common BMP header and per-peer header is the following: 715 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Local Address (16 bytes) | 718 ~ ~ 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Local Port | Remote Port | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Sent OPEN Message | 723 ~ ~ 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Received OPEN Message | 726 ~ ~ 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Information (variable) | 729 ~ ~ 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 o Local Address: The local IP address associated with the peering 733 TCP session. It is 4 bytes long if an IPv4 address is carried in 734 this field, as determined by the V flag (with the 12 most 735 significant bytes zero-filled) and 16 bytes long if an IPv6 736 address is carried in this field. 738 o Local Port: The local port number associated with the peering TCP 739 session, or zero if no TCP session actually exists (see 740 Section 8.2). 742 o Remote Port: The remote port number associated with the peering 743 TCP session, or zero if no TCP session actually exists (see 744 Section 8.2). (The remote address can be found in the Peer 745 Address field of the fixed header.) 747 o Sent OPEN Message: The full OPEN message transmitted by the 748 monitored router to its peer. 750 o Received OPEN Message: The full OPEN message received by the 751 monitored router from its peer. 753 o Information: Information about the peer, using the Information TLV 754 (Section 4.4) format. Only the string type is defined in this 755 context; it may be repeated. Inclusion of the Information field 756 is OPTIONAL. Its presence or absence can be inferred by 757 inspection of the Message Length in the common header. 759 5. Route Monitoring 761 In BMP's normal operating mode, after the BMP session is up, Route 762 Monitoring messages are used to provide a snapshot of the Adj-RIB-In 763 of each monitored peer. This is done by sending all routes stored in 764 the Adj-RIB-In of those peers using standard BGP Update messages, 765 encapsulated in Route Monitoring messages. There is no requirement 766 on the ordering of messages in the peer dumps. When the initial dump 767 is completed for a given peer, this MUST be indicated by sending an 768 End-of-RIB marker for that peer (as specified in Section 2 of 769 [RFC4724], plus the BMP encapsulation header). See also Section 9. 771 A BMP speaker may send pre-policy routes, post-policy routes, or 772 both. The selection may be due to implementation constraints (it is 773 possible a BGP implementation may not store, for example, routes that 774 have been filtered out by policy). Pre-policy routes MUST have their 775 L flag clear in the BMP header (see Section 4), post-policy routes 776 MUST have their L flag set. When an implementation chooses to send 777 both pre- and post-policy routes, it is effectively multiplexing two 778 update streams onto the BMP session. The streams are distinguished 779 by their L flags. 781 If the implementation is able to provide information about when 782 routes were received, it MAY provide such information in the BMP 783 timestamp field. Otherwise, the BMP timestamp field MUST be set to 784 zero, indicating time is not available. 786 Ongoing monitoring is accomplished by propagating route changes in 787 BGP Update PDUs and forwarding those PDUs to the monitoring station, 788 again using RM messages. When a change occurs to a route, such as an 789 attribute change, the router must update the monitoring station with 790 the new attribute. As discussed above, it MAY generate either an 791 update with the L flag clear, with it set, or two updates, one with 792 the L flag clear and the other with the L flag set. When a route is 793 withdrawn by a peer, a corresponding withdraw is sent to the 794 monitoring station. The withdraw MUST have its L flag set to 795 correspond to that of any previous announcement; if the route in 796 question was previously announced with L flag both clear and set, the 797 withdraw MUST similarly be sent twice, with L flag clear and set. 798 Multiple changed routes MAY be grouped into a single BGP UPDATE PDU 799 when feasible, exactly as in the standard BGP protocol. 801 It's important to note RM messages are not replicated messages 802 received from a peer. (Route mirroring (Section 6) is provided if 803 this is required.) While the router should attempt to generate 804 updates promptly there is a finite time that could elapse between 805 reception of an update, the generation an RM message, and its 806 transmission to the monitoring station. If there are state changes 807 in the interim for that prefix, it is acceptable that the router 808 generate the final state of that prefix to the monitoring station. 809 This is sometimes known as "state compression". The actual PDU 810 generated and transmitted to the station might also differ from the 811 exact PDU received from the peer, for example due to differences 812 between how different implementations format path attributes. 814 6. Route Mirroring 816 Route Mirroring messages are provided for two primary reasons: First, 817 to enable an implementation to operate in a mode where it provides a 818 full-fidelity view of all messages received from its peers, without 819 state compression. As we note in Section 5, BMP's normal operational 820 mode cannot provide this. Implementors are strongly cautioned that 821 without state compression, an implementation could require unbounded 822 storage to buffer messages queued to be mirrored. Route Mirroring is 823 unlikely to be suitable for implementation in conventional routers, 824 and its use is NOT RECOMMENDED except in cases where implementors 825 have carefully considered the tradeoffs. These tradeoffs include: 826 router resource exhaustion, the potential to flow-block BGP peers, 827 and the slowing of routing convergence. 829 The second application for Route Mirroring is for error reporting and 830 diagnosis. When [RFC7606] is in use, a router can process BGP 831 messages that are determined to contain errors, without resetting the 832 BGP session. Such messages MAY be mirrored. The buffering used for 833 such mirroring SHOULD be limited. If an errored message is unable to 834 be mirrored due to buffer exhaustion, a message with the "Messages 835 Lost" code SHOULD be sent to indicate this. (This implies a buffer 836 should be reserved for this use.) 838 7. Stat Reports 840 As outlined above, SR messages are used to monitor specific events 841 and counters on the monitored router. One type of monitoring could 842 be to find out if there are an undue number of route advertisements 843 and withdraws happening (churn) on the monitored router. Another 844 metric is to evaluate the number of looped AS-Paths on the router. 846 While this document proposes a small set of counters to begin with, 847 the authors envision this list may grow in the future with new 848 applications that require BMP-style monitoring. 850 8. Other Considerations 851 8.1. Multiple Instances 853 Some routers may support multiple instances of the BGP protocol, for 854 example as "logical routers" or through some other facility. The BMP 855 protocol relates to a single instance of BGP; thus, if a router 856 supports multiple BGP instances it should also support multiple BMP 857 instances (one per BGP instance). Different BMP instances SHOULD 858 generate Initiation Messages that are distinct from one another, for 859 example by using distinguishable sysNames or by inclusion of 860 instance-identifying information in a string TLV. 862 8.2. Locally-Originated Routes 864 Some consideration is required for routes originated into BGP by the 865 local router, whether as a result of redistribution from a another 866 protocol or for some other reason. 868 Such routes can be modeled as having been sent by the router to 869 itself, placing the router's own address in the Peer Address field of 870 the header. It is RECOMMENDED that when doing so the router should 871 use the same address it has used as its local address for the BMP 872 session. Since in this case no transport session actually exists the 873 Local and Remote Port fields of the Peer Up message MUST be set to 874 zero. Clearly the OPEN Message fields of the Peer Up message will 875 equally not have been physically transmitted, but should represent 876 the relevant capabilities of the local router. 878 Also recall the L flag is used to indicate locally-sourced routes, 879 see Section 4.2. 881 9. Using BMP 883 Once the BMP session is established route monitoring starts dumping 884 the current snapshot as well as incremental changes simultaneously. 886 It is fine to have these operations occur concurrently. If the 887 initial dump visits a route and subsequently a withdraw is received, 888 this will be forwarded to the monitoring station that would have to 889 correlate and reflect the deletion of that route in its internal 890 state. This is an operation a monitoring station would need to 891 support regardless. 893 If the router receives a withdraw for a prefix even before the peer 894 dump procedure visits that prefix, then the router would clean up 895 that route from its internal state and will not forward it to the 896 monitoring station. In this case, the monitoring station may receive 897 a bogus withdraw it can safely ignore. 899 10. IANA Considerations 901 IANA is requested to create registries for the following BMP 902 parameters, to be organized in a new group "BGP Monitoring Protocol 903 (BMP) Parameters": 905 10.1. BMP Message Types 907 This document defines seven message types for transferring BGP 908 messages between cooperating systems (Section 4): 910 o Type 0: Route Monitoring 911 o Type 1: Statistics Report 912 o Type 2: Peer Down Notification 913 o Type 3: Peer Up Notification 914 o Type 4: Initiation 915 o Type 5: Termination 916 o Type 6: Route Mirroring 918 Type values 0 through 128 MUST be assigned using the "Standards 919 Action" policy, and values 129 through 250 using the "Specification 920 Required" policy defined in [RFC5226]. Values 251 through 254 are 921 "Experimental" and value 255 is reserved. 923 10.2. BMP Peer Types 925 This document defines two types of peers for purposes of interpreting 926 the Peer Distinguisher field (Section 4.2): 928 o Peer Type = 0: Global Instance Peer. 929 o Peer Type = 1: RD Instance Peer. 930 o Peer Type = 2: Local Instance Peer. 932 Peer Type values 0 through 127 MUST be assigned using the "Standards 933 Action" policy, and values 128 through 250 using the "Specification 934 Required" policy, defined in [RFC5226]. Values 251 through 254 are 935 "Experimental" and value 255 is reserved. 937 10.3. BMP Peer Flags 939 This document defines three bit flags in the Peer Flags field of the 940 Per-Peer Header (Section 4.2). The bits are numbered from zero (the 941 high-order, or leftmost, bit) to seven (the low-order, or rightmost, 942 bit): 944 o Flag 0: V flag. 945 o Flag 1: L flag. 946 o Flag 2: A flag. 948 Flags 3 through 7 MUST be assigned using the "Standards Action" 949 policy. 951 10.4. BMP Statistics Types 953 This document defines fourteen statistics types for statistics 954 reporting (Section 4.8): 956 o Stat Type = 0: Number of prefixes rejected by inbound policy. 957 o Stat Type = 1: Number of (known) duplicate prefix advertisements. 958 o Stat Type = 2: Number of (known) duplicate withdraws. 959 o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST 960 loop. 961 o Stat Type = 4: Number of updates invalidated due to AS_PATH loop. 962 o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID. 963 o Stat Type = 6: Number of updates invalidated due to a loop found 964 in AS_CONFED_SEQUENCE or AS_CONFED_SET. 965 o Stat Type = 7: Number of routes in Adj-RIBs-In. 966 o Stat Type = 8: Number of routes in Loc-RIB. 967 o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. 968 o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. 969 o Stat Type = 11: Number of updates subjected to treat-as-withdraw. 970 o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw. 971 o Stat Type = 13: Number of duplicate update messages received. 973 Stat Type values 0 through 32767 MUST be assigned using the 974 "Standards Action" policy, and values 32768 through 65530 using the 975 "Specification Required" policy, defined in [RFC5226]. Values 65531 976 through 65534 are "Experimental" and value 65535 is reserved. 978 10.5. BMP Initiation Message TLVs 980 This document defines three types for information carried in the 981 Initiation message (Section 4.3): 983 o Type = 0: String. 984 o Type = 1: sysDescr. 985 o Type = 2: sysName. 987 Information type values 0 through 32767 MUST be assigned using the 988 "Standards Action" policy, and values 32768 through 65530 using the 989 "Specification Required" policy, defined in [RFC5226]. Values 65531 990 through 65534 are "Experimental" and value 65535 is reserved. 992 10.6. BMP Termination Message TLVs 994 This document defines two types for information carried in the 995 Termination message (Section 4.5): 997 o Type = 0: String. 998 o Type = 1: Reason. 1000 Information type values 0 through 32767 MUST be assigned using the 1001 "Standards Action" policy, and values 32768 through 65530 using the 1002 "Specification Required" policy, defined in [RFC5226]. Values 65531 1003 through 65534 are "Experimental" and value 65535 is reserved. 1005 10.7. BMP Termination Message Reason Codes 1007 This document defines five types for information carried in the 1008 Termination message (Section 4.5) Reason code,: 1010 o Type = 0: Administratively closed. 1011 o Type = 1: Unspecified reason. 1012 o Type = 2: Out of resources. 1013 o Type = 3: Redundant connection. 1014 o Type = 4: Permanently administratively closed. 1016 Information type values 0 through 32767 MUST be assigned using the 1017 "Standards Action" policy, and values 32768 through 65530 using the 1018 "Specification Required" policy, defined in [RFC5226]. Values 65531 1019 through 65534 are "Experimental" and value 65535 is reserved. 1021 10.8. BMP Peer Down Reason Codes 1023 This document defines five types for information carried in the Peer 1024 Down Notification (Section 4.9) Reason code (and reserves one further 1025 type): 1027 o Type = 0 is reserved. 1028 o Type = 1: Local system closed, NOTIFICATION PDU follows. 1029 o Type = 2: Local system closed, FSM Event follows. 1030 o Type = 3: Remote system closed, NOTIFICATION PDU follows. 1031 o Type = 4: Remote system closed, no data. 1032 o Type = 5: Peer de-configured. 1034 Information type values 0 through 32767 MUST be assigned using the 1035 "Standards Action" policy, and values 32768 through 65530 using the 1036 "Specification Required" policy, defined in [RFC5226]. Values 65531 1037 through 65534 are "Experimental" and values 0 and 65535 are reserved. 1039 10.9. Route Mirroring TLVs 1041 This document defines two types for information carried in the Route 1042 Mirroring message (Section 4.7): 1044 o Type = 0: BGP Message. 1045 o Type = 1: Information. 1047 Information type values 0 through 32767 MUST be assigned using the 1048 "Standards Action" policy, and values 32768 through 65530 using the 1049 "Specification Required" policy, defined in [RFC5226]. Values 65531 1050 through 65534 are "Experimental" and value 65535 is reserved. 1052 10.10. BMP Route Mirroring Information Codes 1054 This document defines two types for information carried in the Route 1055 Mirroring Information (Section 4.7) code: 1057 o Type = 0: Errored PDU. 1058 o Type = 1: Messages Lost. 1060 Information type values 0 through 32767 MUST be assigned using the 1061 "Standards Action" policy, and values 32768 through 65530 using the 1062 "Specification Required" policy, defined in [RFC5226]. Values 65531 1063 through 65534 are "Experimental" and value 65535 is reserved. 1065 11. Security Considerations 1067 This document defines a mechanism to obtain a full dump or provide 1068 continuous monitoring of a BGP speaker's BGP routes, including 1069 received BGP messages. This capability could allow an outside party 1070 to obtain information not otherwise obtainable. For example, 1071 although it's hard to consider the content of BGP routes in the 1072 public Internet to be confidential, BGP is used in private contexts 1073 as well, for example for L3VPN [RFC4364]. As another example, a 1074 clever attacker might be able to infer the content of the monitored 1075 router's import policy by comparing the pre-policy routes exposed by 1076 BMP, to post-policy routes exported in BGP. 1078 Implementations of this protocol SHOULD require manual configuration 1079 of the monitored and monitoring devices. 1081 Unless a transport that provides mutual authentication is used, an 1082 attacker could masquerade as the monitored router and trick a 1083 monitoring station into accepting false information, or could 1084 masquerade as a monitoring station and gain unauthorized access to 1085 BMP data. Unless a transport that provides confidentiality is used, 1086 a passive or active attacker could gain access to or tamper with the 1087 BMP data in flight. 1089 Where the security considerations outlined above are a concern, users 1090 of this protocol should use IPsec [RFC4303] in tunnel mode with 1091 preshared keys. 1093 12. Acknowledgements 1095 Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, 1096 Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack 1097 McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom 1098 Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members 1099 of the GROW working group for their comments. 1101 13. References 1103 13.1. Normative References 1105 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1106 for Network Management of TCP/IP-based internets: MIB-II", 1107 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 1108 . 1110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14, RFC 2119, 1112 DOI 10.17487/RFC2119, March 1997, 1113 . 1115 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1116 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1117 DOI 10.17487/RFC4271, January 2006, 1118 . 1120 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1121 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1122 DOI 10.17487/RFC4724, January 2007, 1123 . 1125 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1126 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1127 DOI 10.17487/RFC5226, May 2008, 1128 . 1130 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 1131 Autonomous System (AS) Number Space", RFC 6793, 1132 DOI 10.17487/RFC6793, December 2012, 1133 . 1135 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1136 Patel, "Revised Error Handling for BGP UPDATE Messages", 1137 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1138 . 1140 13.2. Informative References 1142 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 1143 of management information for TCP/IP-based internets", 1144 STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, 1145 . 1147 [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual 1148 Conventions for Additional High Capacity Data Types", 1149 RFC 2856, DOI 10.17487/RFC2856, June 2000, 1150 . 1152 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1153 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1154 . 1156 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1157 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1158 2006, . 1160 Appendix A. Changes Between BMP Versions 1 and 2 1162 o Added Peer Up Message 1163 o Added L flag 1164 o Editorial changes 1166 Appendix B. Changes Between BMP Versions 2 and 3 1168 o Added a 32-bit length field to the fixed header. 1169 o Clarified error handling. 1170 o Added new stat types: 5 (number of updates invalidated due to 1171 ORIGINATOR_ID), 6 (number of updates invalidated due to 1172 AS_CONFED_SEQUENCE/AS_CONFED_SET), 7 (number of routes in Adj-RIB- 1173 In), 8 (number of routes in Loc-RIB), 9 (number of routes in Adj- 1174 RIB-In, per AFI/SAFI), 10 (numer of routes in Loc-RIB, per AFI/ 1175 SAFI), 11 (number of updates subjected to treat-as-withdraw 1176 treatment), 12 (number of prefixes subjected to treat-as-withdraw 1177 treatment), and 13 (number of duplicate update messages received). 1178 o Defined counters and gauges for use with stat types. 1179 o For peer down messages, the relevant FSM event is to be sent in 1180 type 2 messages. Added type 5 to indicate peer is no longer 1181 monitored. 1183 o Added local address and local and remote ports to the peer up 1184 message. Also optional descriptive string. 1185 o Require End-of-RIB marker after initial dump. 1186 o Added Initiation message with string content. 1187 o Permit multiplexing pre- and post-policy feeds onto a single BMP 1188 session. 1189 o Changed assignment policy for IANA registries. 1190 o Changed "Loc-RIB" references to refer to "Post-Policy Adj-RIB-In", 1191 plus other editorial changes. 1192 o Introduced option for monitoring station to be active party in 1193 initiating connection. 1194 o Introduced Termination message. 1195 o Added "route mirroring" mode. 1196 o Added "A" flag to identify AS Path format in use. 1198 Authors' Addresses 1200 John Scudder (editor) 1201 Juniper Networks 1202 1194 N. Mathilda Ave 1203 Sunnyvale, CA 94089 1204 USA 1206 Email: jgs@juniper.net 1208 Rex Fernando 1209 Cisco Systems 1210 170 W. Tasman Dr. 1211 San Jose, CA 95134 1212 USA 1214 Email: rex@cisco.com 1216 Stephen Stuart 1217 Google 1218 1600 Amphitheatre Parkway 1219 Mountain View, CA 94043 1220 USA 1222 Email: sstuart@google.com