diff options
Diffstat (limited to 'doc/rfc/rfc7854.txt')
| -rw-r--r-- | doc/rfc/rfc7854.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc7854.txt b/doc/rfc/rfc7854.txt new file mode 100644 index 0000000..6e33b27 --- /dev/null +++ b/doc/rfc/rfc7854.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Scudder, Ed. +Request for Comments: 7854 Juniper Networks +Category: Standards Track R. Fernando +ISSN: 2070-1721 Cisco Systems + S. Stuart + Google + June 2016 + + + BGP Monitoring Protocol (BMP) + +Abstract + + This document defines the BGP Monitoring Protocol (BMP), which can be + used to monitor BGP sessions. BMP is intended to provide a + convenient interface for obtaining route views. Prior to the + introduction of BMP, screen scraping was the most commonly used + approach to obtaining such views. The design goals are to keep BMP + simple, useful, easily implemented, and minimally service affecting. + BMP is not suitable for use as a routing protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7854. + + + + + + + + + + + + + + + + + +Scudder, et al. Standards Track [Page 1] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Scudder, et al. Standards Track [Page 2] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Overview of BMP Operation . . . . . . . . . . . . . . . . . . 4 + 3.1. BMP Messages . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Connection Establishment and Termination . . . . . . . . 5 + 3.3. Lifecycle of a BMP Session . . . . . . . . . . . . . . . 6 + 4. BMP Message Format . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Per-Peer Header . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Initiation Message . . . . . . . . . . . . . . . . . . . 10 + 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 10 + 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 11 + 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 12 + 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 12 + 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 13 + 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 16 + 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 17 + 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 19 + 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 19 + 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 20 + 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 20 + 8.2. Locally Originated Routes . . . . . . . . . . . . . . . . 20 + 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 21 + 10.2. BMP Peer Types . . . . . . . . . . . . . . . . . . . . . 21 + 10.3. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 22 + 10.4. BMP Statistics Types . . . . . . . . . . . . . . . . . . 22 + 10.5. BMP Initiation Message TLVs . . . . . . . . . . . . . . 23 + 10.6. BMP Termination Message TLVs . . . . . . . . . . . . . . 23 + 10.7. BMP Termination Message Reason Codes . . . . . . . . . . 23 + 10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 24 + 10.9. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 24 + 10.10. BMP Route Mirroring Information Codes . . . . . . . . . 24 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 + 12.2. Informative References . . . . . . . . . . . . . . . . . 26 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 + + + + + + + +Scudder, et al. Standards Track [Page 3] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +1. Introduction + + Many researchers and network operators wish to have access to the + contents of routers' BGP Routing Information Bases (RIBs) as well as + a view of protocol updates the router is receiving. This monitoring + task cannot be realized by standard protocol mechanisms. Prior to + the introduction of BMP, this data could only be obtained through + screen scraping. + + BMP provides access to the Adj-RIB-In of a peer on an ongoing basis + and a periodic dump of certain statistics the monitoring station can + use for further analysis. From a high level, BMP can be thought of + as the result of multiplexing together the messages received on the + various monitored BGP sessions. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119 [RFC2119]. + +2. Definitions + + o Adj-RIB-In: As defined in [RFC4271], "The Adj-RIBs-In contains + unprocessed routing information that has been advertised to the + local BGP speaker by its peers." This is also referred to as the + pre-policy Adj-RIB-In in this document. + + o Post-Policy Adj-RIB-In: The result of applying inbound policy to + an Adj-RIB-In, but prior to the application of route selection to + form the Loc-RIB. + +3. Overview of BMP Operation + +3.1. BMP Messages + + The following are the messages provided by BMP: + + o Route Monitoring (RM): Used to provide an initial dump of all + routes received from a peer, as well as an ongoing mechanism that + sends the incremental routes advertised and withdrawn by a peer to + the monitoring station. + + o Peer Down Notification: A message sent to indicate that a peering + session has gone down with information indicating the reason for + the session disconnect. + + + + +Scudder, et al. Standards Track [Page 4] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + o Stats Reports (SR): An ongoing dump of statistics that can be used + by the monitoring station as a high-level indication of the + activity going on in the router. + + o Peer Up Notification: A message sent to indicate that a peering + session has come up. The message includes information regarding + the data exchanged between the peers in their OPEN messages, as + well as information about the peering TCP session itself. In + addition to being sent whenever a peer transitions to the + Established state, a Peer Up Notification is sent for each peer in + the Established state when the BMP session itself comes up. + + o Initiation: A means for the monitored router to inform the + monitoring station of its vendor, software version, and so on. + + o Termination: A means for the monitored router to inform the + monitoring station of why it is closing a BMP session. + + o Route Mirroring: A means for the monitored router to send verbatim + duplicates of messages as received. Can be used to exactly mirror + a monitored BGP session. Can also be used to report malformed BGP + Protocol Data Units (PDUs). + +3.2. Connection Establishment and Termination + + BMP operates over TCP. All options are controlled by configuration + on the monitored router. No BMP message is ever sent from the + monitoring station to the monitored router. The monitored router MAY + take steps to prevent the monitoring station from sending data (for + example, by half-closing the TCP session or setting its window size + to 0) or it MAY silently discard any data sent by the monitoring + station. + + The router may be monitored by one or more monitoring stations. With + respect to each (router and monitoring station) pair, one party is + active with respect to TCP session establishment, and the other party + is passive. Which party is active and which is passive is controlled + by configuration. + + The passive party is configured to listen on a particular TCP port + and the active party is configured to establish a connection to that + port. If the active party is unable to connect to the passive party, + it periodically retries the connection. Retries MUST be subject to + some variety of backoff. Exponential backoff with a default initial + backoff of 30 seconds and a maximum of 720 seconds is suggested. + + + + + + +Scudder, et al. Standards Track [Page 5] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + The router MAY restrict the set of IP addresses from which it will + accept connections. It SHOULD restrict the number of simultaneous + connections it will permit from a given IP address. The default + value for this restriction SHOULD be 1, though an implementation MAY + permit this restriction to be disabled in configuration. The router + MUST also restrict the rate at which sessions may be established. A + suggested default is an establishment rate of 2 sessions per minute. + + A router (or management station) MAY implement logic to detect + redundant connections, as might occur if both parties are configured + to be active, and MAY elect to terminate redundant connections. A + Termination reason code is defined for this purpose. + + Once a connection is established, the router sends messages over it. + There is no initialization or handshaking phase, messages are simply + sent as soon as the connection is established. + + If the monitoring station intends to end or restart BMP processing, + it simply drops the connection. + +3.3. Lifecycle of a BMP Session + + A router is configured to speak BMP to one or more monitoring + stations. It MAY be configured to send monitoring information for + only a subset of its BGP peers. Otherwise, all BGP peers are assumed + to be monitored. + + A BMP session begins when the active party (either router or + management station, as determined by configuration) successfully + opens a TCP session (the "BMP session"). Once the session is up, the + router begins to send BMP messages. It MUST begin by sending an + Initiation message. It subsequently sends a Peer Up message over the + BMP session for each of its monitored BGP peers that is in the + Established state. It follows by sending the contents of its Adj- + RIBs-In (pre-policy, post-policy, or both, see Section 5) + encapsulated in Route Monitoring messages. Once it has sent all the + routes for a given peer, it MUST send an End-of-RIB message for that + peer; when End-of-RIB has been sent for each monitored peer, the + initial table dump has completed. (A monitoring station that only + wants to gather a table dump could close the connection once it has + gathered an End-of-RIB or Peer Down message corresponding to each + Peer Up message.) + + Following the initial table dump, the router sends incremental + updates encapsulated in Route Monitoring messages. It MAY + periodically send Stats Reports or even new Initiation messages, + according to configuration. If any new monitored BGP peer becomes + Established, a corresponding Peer Up message is sent. If any BGP + + + +Scudder, et al. Standards Track [Page 6] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + peers for which Peer Up messages were sent transition out of the + Established state, corresponding Peer Down messages are sent. + + A BMP session ends when the TCP session that carries it is closed for + any reason. The router MAY send a Termination message prior to + closing the session. + +4. BMP Message Format + +4.1. Common Header + + The following common header appears in all BMP messages. The rest of + the data in a BMP message is dependent on the Message Type field in + the common header. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+ + | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg. Type | + +---------------+ + + o Version (1 byte): Indicates the BMP version. This is set to '3' + for all messages defined in this specification. ('1' and '2' were + used by draft versions of this document.) Version 0 is reserved + and MUST NOT be sent. + + o Message Length (4 bytes): Length of the message in bytes + (including headers, data, and encapsulated messages, if any). + + o Message Type (1 byte): This identifies the type of the BMP + message. A BMP implementation MUST ignore unrecognized message + types upon receipt. + + * Type = 0: Route Monitoring + * Type = 1: Statistics Report + * Type = 2: Peer Down Notification + * Type = 3: Peer Up Notification + * Type = 4: Initiation Message + * Type = 5: Termination Message + * Type = 6: Route Mirroring Message + + + + + + + +Scudder, et al. Standards Track [Page 7] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +4.2. Per-Peer Header + + The per-peer header follows the common header for most BMP messages. + The rest of the data in a BMP message is dependent on the Message + Type field in the common header. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer Type | Peer Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer Distinguisher (present based on peer type) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer Address (16 bytes) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer AS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer BGP ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (seconds) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (microseconds) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Peer Type (1 byte): Identifies the type of peer. Currently, three + types of peers are identified: + + * Peer Type = 0: Global Instance Peer + * Peer Type = 1: RD Instance Peer + * Peer Type = 2: Local Instance Peer + + o Peer Flags (1 byte): These flags provide more information about + the peer. The flags are defined as follows: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |V|L|A| Reserved| + +-+-+-+-+-+-+-+-+ + + * The V flag indicates that the Peer address is an IPv6 address. + For IPv4 peers, this is set to 0. + + + + + + + + +Scudder, et al. Standards Track [Page 8] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + * The L flag, if set to 1, indicates that the message reflects + the post-policy Adj-RIB-In (i.e., its path attributes reflect + the application of inbound policy). It is set to 0 if the + message reflects the pre-policy Adj-RIB-In. Locally sourced + routes also carry an L flag of 1. See Section 5 for further + detail. This flag has no significance when used with route + mirroring messages (Section 4.7). + + * The A flag, if set to 1, indicates that the message is + formatted using the legacy 2-byte AS_PATH format. If set to 0, + the message is formatted using the 4-byte AS_PATH format + [RFC6793]. A BMP speaker MAY choose to propagate the AS_PATH + information as received from its peer, or it MAY choose to + reformat all AS_PATH information into a 4-byte format + regardless of how it was received from the peer. In the latter + case, AS4_PATH or AS4_AGGREGATOR path attributes SHOULD NOT be + sent in the BMP UPDATE message. This flag has no significance + when used with route mirroring messages (Section 4.7). + + * The remaining bits are reserved for future use. They MUST be + transmitted as 0 and their values MUST be ignored on receipt. + + o Peer Distinguisher (8 bytes): Routers today can have multiple + instances (example: Layer 3 Virtual Private Networks (L3VPNs) + [RFC4364]). This field is present to distinguish peers that + belong to one address domain from the other. + + If the peer is a "Global Instance Peer", this field is zero- + filled. If the peer is a "RD Instance Peer", it is set to the + route distinguisher of the particular instance the peer belongs + to. If the peer is a "Local Instance Peer", it is set to a + unique, locally defined value. In all cases, the effect is that + the combination of the Peer Type and Peer Distinguisher is + sufficient to disambiguate peers for which other identifying + information might overlap. + + o Peer Address: The remote IP address associated with the TCP + session over which the encapsulated PDU was received. It is 4 + bytes long if an IPv4 address is carried in this field (with the + 12 most significant bytes zero-filled) and 16 bytes long if an + IPv6 address is carried in this field. + + o Peer AS: The Autonomous System number of the peer from which the + encapsulated PDU was received. If a 16-bit AS number is stored in + this field [RFC6793], it should be padded with zeroes in the 16 + most significant bits. + + + + + +Scudder, et al. Standards Track [Page 9] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + o Peer BGP ID: The BGP Identifier of the peer from which the + encapsulated PDU was received. + + o Timestamp: The time when the encapsulated routes were received + (one may also think of this as the time when they were installed + in the Adj-RIB-In), expressed in seconds and microseconds since + midnight (zero hour), January 1, 1970 (UTC). If zero, the time is + unavailable. Precision of the timestamp is implementation- + dependent. + +4.3. Initiation Message + + The initiation message provides a means for the monitored router to + inform the monitoring station of its vendor, software version, and so + on. An initiation message MUST be sent as the first message after + the TCP session comes up. An initiation message MAY be sent at any + point thereafter, if warranted by a change on the monitored router. + + The initiation message consists of the common BMP header followed by + two or more Information TLVs (Section 4.4) containing information + about the monitored router. The sysDescr and sysName Information + TLVs MUST be sent, any others are optional. The string TLV MAY be + included multiple times. + +4.4. Information TLV + + The Information TLV is used by the Initiation (Section 4.3) and Peer + Up (Section 4.10) messages. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Information Type | Information Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Information (variable) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Information Type (2 bytes): Type of information provided. Defined + types are: + + * Type = 0: String. The Information field contains a free-form + UTF-8 string whose length is given by the Information Length + field. The value is administratively assigned. There is no + requirement to terminate the string with a null (or any other + particular) character -- the Information Length field gives its + termination. If multiple strings are included, their ordering + MUST be preserved when they are reported. + + + +Scudder, et al. Standards Track [Page 10] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + * Type = 1: sysDescr. The Information field contains an ASCII + string whose value MUST be set to be equal to the value of the + sysDescr MIB-II [RFC1213] object. + + * Type = 2: sysName. The Information field contains an ASCII + string whose value MUST be set to be equal to the value of the + sysName MIB-II [RFC1213] object. + + o Information Length (2 bytes): The length of the following + Information field, in bytes. + + o Information (variable): Information about the monitored router, + according to the type. + +4.5. Termination Message + + The termination message provides a way for a monitored router to + indicate why it is terminating a session. Although use of this + message is RECOMMENDED, a monitoring station must always be prepared + for the session to terminate with no message. Once the router has + sent a termination message, it MUST close the TCP session without + sending any further messages. Likewise, the monitoring station MUST + close the TCP session after receiving a termination message. + + The termination message consists of the common BMP header followed by + one or more TLVs containing information about the reason for the + termination, as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Information Type | Information Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Information (variable) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Information Type (2 bytes): Type of information provided. Defined + types are: + + * Type = 0: String. The Information field contains a free-form + UTF-8 string whose length is given by the Information Length + field. Inclusion of this TLV is optional. It MAY be used to + provide further detail for any of the defined reasons. + Multiple String TLVs MAY be included in the message. + + + + + + +Scudder, et al. Standards Track [Page 11] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + * Type = 1: Reason. The Information field contains a 2-byte code + indicating the reason that the connection was terminated. Some + reasons may have further TLVs associated with them. Inclusion + of this TLV is REQUIRED. Defined reasons are: + + + Reason = 0: Session administratively closed. The session + might be re-initiated. + + + Reason = 1: Unspecified reason. + + + Reason = 2: Out of resources. The router has exhausted + resources available for the BMP session. + + + Reason = 3: Redundant connection. The router has determined + that this connection is redundant with another one. + + + Reason = 4: Session permanently administratively closed, + will not be re-initiated. Monitoring station should reduce + (potentially to 0) the rate at which it attempts + reconnection to the monitored router. + + o Information Length (2 bytes): The length of the following + Information field, in bytes. + + o Information (variable): Information about the monitored router, + according to the type. + +4.6. Route Monitoring + + Route Monitoring messages are used for initial synchronization of the + ADJ-RIBs-In. They are also used for ongoing monitoring of the + ADJ-RIB-In state. Route monitoring messages are state-compressed. + This is all discussed in more detail in Section 5. + + Following the common BMP header and per-peer header is a BGP Update + PDU. + +4.7. Route Mirroring + + Route Mirroring messages are used for verbatim duplication of + messages as received. A possible use for mirroring is exact + mirroring of one or more monitored BGP sessions, without state + compression. Another possible use is the mirroring of messages that + have been treated-as-withdraw [RFC7606], for debugging purposes. + Mirrored messages may be sampled, or may be lossless. The Messages + Lost Information code is provided to allow losses to be indicated. + Section 6 provides more detail. + + + + +Scudder, et al. Standards Track [Page 12] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + Following the common BMP header and per-peer header is a set of TLVs + that contain information about a message or set of messages. Each + TLV comprises a 2-byte type code, a 2-byte length field, and a + variable-length value. Inclusion of any given TLV is OPTIONAL; + however, at least one TLV SHOULD be included, otherwise there's no + point in sending the message. Defined TLVs are as follows: + + o Type = 0: BGP Message. A BGP PDU. This PDU may or may not be an + Update message. If the BGP Message TLV occurs in the Route + Mirroring message, it MUST occur last in the list of TLVs. + + o Type = 1: Information. A 2-byte code that provides information + about the mirrored message or message stream. Defined codes are: + + * Code = 0: Errored PDU. The contained message was found to have + some error that made it unusable, causing it to be treated-as- + withdraw [RFC7606]. A BGP Message TLV MUST also occur in the + TLV list. + + * Code = 1: Messages Lost. One or more messages may have been + lost. This could occur, for example, if an implementation runs + out of available buffer space to queue mirroring messages. + + A Route Mirroring message may be sent any time it would be legal to + send a Route Monitoring message. + +4.8. Stats Reports + + These messages contain information that could be used by the + monitoring station to observe interesting events that occur on the + router. + + Transmission of SR messages could be timer triggered or event driven + (for example, when a significant event occurs or a threshold is + reached). This specification does not impose any timing restrictions + on when and on what event these reports have to be transmitted. It + is left to the implementation to determine transmission timings -- + however, configuration control should be provided of the timer and/or + threshold values. This document only specifies the form and content + of SR messages. + + Following the common BMP header and per-peer header is a 4-byte field + that indicates the number of counters in the stats message where each + counter is encoded as a TLV. + + + + + + + +Scudder, et al. Standards Track [Page 13] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stats Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Each counter is encoded as follows: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stat Type | Stat Len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Stat Data | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Stat Type (2 bytes): Defines the type of the statistic carried in + the Stat Data field. + + o Stat Len (2 bytes): Defines the length of the Stat Data field. + + This specification defines the following statistics. A BMP + implementation MUST ignore unrecognized stat types on receipt, and + likewise MUST ignore unexpected data in the Stat Data field. + + Stats are either counters or gauges, defined as follows after the + examples in Section 3.2.3.3 of [RFC1155] and Section 4 of [RFC2856], + respectively: + + 32-bit Counter: A non-negative integer that monotonically increases + until it reaches a maximum value, when it wraps around and starts + increasing again from 0. It has a maximum value of 2^32-1 + (4294967295 decimal). + + 64-bit Gauge: A non-negative integer that may increase or decrease, + but shall never exceed a maximum value, nor fall below a minimum one. + The maximum value cannot be greater than 2^64-1 (18446744073709551615 + decimal), and the minimum value cannot be smaller than 0. The value + has its maximum value whenever the information being modeled is + greater than or equal to its maximum value, and has its minimum value + whenever the information being modeled is smaller than or equal to + its minimum value. If the information being modeled subsequently + decreases below the maximum value (or increases above the minimum + value), the 64-bit Gauge also decreases (or increases). + + o Stat Type = 0: (32-bit Counter) Number of prefixes rejected by + inbound policy. + + + +Scudder, et al. Standards Track [Page 14] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + o Stat Type = 1: (32-bit Counter) Number of (known) duplicate prefix + advertisements. + + o Stat Type = 2: (32-bit Counter) Number of (known) duplicate + withdraws. + + o Stat Type = 3: (32-bit Counter) Number of updates invalidated due + to CLUSTER_LIST loop. + + o Stat Type = 4: (32-bit Counter) Number of updates invalidated due + to AS_PATH loop. + + o Stat Type = 5: (32-bit Counter) Number of updates invalidated due + to ORIGINATOR_ID. + + o Stat Type = 6: (32-bit Counter) Number of updates invalidated due + to AS_CONFED loop. + + o Stat Type = 7: (64-bit Gauge) Number of routes in Adj-RIBs-In. + + o Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. + + o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The + value is structured as: 2-byte Address Family Identifier (AFI), + 1-byte Subsequent Address Family Identifier (SAFI), followed by a + 64-bit Gauge. + + o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The + value is structured as: 2-byte AFI, 1-byte SAFI, followed by a + 64-bit Gauge. + + o Stat Type = 11: (32-bit Counter) Number of updates subjected to + treat-as-withdraw treatment [RFC7606]. + + o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to + treat-as-withdraw treatment [RFC7606]. + + o Stat Type = 13: (32-bit Counter) Number of duplicate update + messages received. + + Although the current specification only specifies 4-byte counters and + 8-byte gauges as "Stat Data", this does not preclude future versions + from incorporating more complex TLV-type "Stat Data" (for example, + one that can carry prefix-specific data). SR messages are optional. + However, if an SR message is transmitted, at least one statistic MUST + be carried in it. + + + + + +Scudder, et al. Standards Track [Page 15] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +4.9. Peer Down Notification + + This message is used to indicate that a peering session was + terminated. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+ + | Reason | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data (present if Reason = 1, 2 or 3) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Reason indicates why the session was closed. Defined values are: + + o Reason 1: The local system closed the session. Following the + Reason is a BGP PDU containing a BGP NOTIFICATION message that + would have been sent to the peer. + + o Reason 2: The local system closed the session. No notification + message was sent. Following the reason code is a 2-byte field + containing the code corresponding to the Finite State Machine + (FSM) Event that caused the system to close the session (see + Section 8.1 of [RFC4271]). Two bytes both set to 0 are used to + indicate that no relevant Event code is defined. + + o Reason 3: The remote system closed the session with a notification + message. Following the Reason is a BGP PDU containing the BGP + NOTIFICATION message as received from the peer. + + o Reason 4: The remote system closed the session without a + notification message. This includes any unexpected termination of + the transport session, so in some cases both the local and remote + systems might consider this to apply. + + o Reason 5: Information for this peer will no longer be sent to the + monitoring station for configuration reasons. This does not, + strictly speaking, indicate that the peer has gone down, but it + does indicate that the monitoring station will not receive updates + for the peer. + + A Peer Down message implicitly withdraws all routes that were + associated with the peer in question. A BMP implementation MAY omit + sending explicit withdraws for such routes. + + + + + + +Scudder, et al. Standards Track [Page 16] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +4.10. Peer Up Notification + + The Peer Up message is used to indicate that a peering session has + come up (i.e., has transitioned into the Established state). + Following the common BMP header and per-peer header is the following: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Address (16 bytes) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Local Port | Remote Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sent OPEN Message | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Received OPEN Message | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Information (variable) | + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + o Local Address: The local IP address associated with the peering + TCP session. It is 4 bytes long if an IPv4 address is carried in + this field, as determined by the V flag (with the 12 most + significant bytes zero-filled) and 16 bytes long if an IPv6 + address is carried in this field. + + o Local Port: The local port number associated with the peering TCP + session, or 0 if no TCP session actually exists (see Section 8.2). + + o Remote Port: The remote port number associated with the peering + TCP session, or 0 if no TCP session actually exists (see + Section 8.2). (The remote address can be found in the Peer + Address field of the fixed header.) + + o Sent OPEN Message: The full OPEN message transmitted by the + monitored router to its peer. + + o Received OPEN Message: The full OPEN message received by the + monitored router from its peer. + + + + + + + + +Scudder, et al. Standards Track [Page 17] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + o Information: Information about the peer, using the Information TLV + (Section 4.4) format. Only the string type is defined in this + context; it may be repeated. Inclusion of the Information field + is OPTIONAL. Its presence or absence can be inferred by + inspection of the Message Length in the common header. + +5. Route Monitoring + + In BMP's normal operating mode, after the BMP session is up, Route + Monitoring messages are used to provide a snapshot of the Adj-RIB-In + of each monitored peer. This is done by sending all routes stored in + the Adj-RIB-In of those peers using standard BGP Update messages, + encapsulated in Route Monitoring messages. There is no requirement + on the ordering of messages in the peer dumps. When the initial dump + is completed for a given peer, this MUST be indicated by sending an + End-of-RIB marker for that peer (as specified in Section 2 of + [RFC4724], plus the BMP encapsulation header). See also Section 9. + + A BMP speaker may send pre-policy routes, post-policy routes, or + both. The selection may be due to implementation constraints (it is + possible that a BGP implementation may not store, for example, routes + that have been filtered out by policy). Pre-policy routes MUST have + their L flag clear in the BMP header (see Section 4), post-policy + routes MUST have their L flag set. When an implementation chooses to + send both pre- and post-policy routes, it is effectively multiplexing + two update streams onto the BMP session. The streams are + distinguished by their L flags. + + If the implementation is able to provide information about when + routes were received, it MAY provide such information in the BMP + Timestamp field. Otherwise, the BMP Timestamp field MUST be set to + 0, indicating that time is not available. + + Ongoing monitoring is accomplished by propagating route changes in + BGP Update PDUs and forwarding those PDUs to the monitoring station, + again using RM messages. When a change occurs to a route, such as an + attribute change, the router must update the monitoring station with + the new attribute. As discussed above, it MAY generate either an + update with the L flag clear, with it set, or two updates, one with + the L flag clear and the other with the L flag set. When a route is + withdrawn by a peer, a corresponding withdraw is sent to the + monitoring station. The withdraw MUST have its L flag set to + correspond to that of any previous announcement; if the route in + question was previously announced with L flag both clear and set, the + withdraw MUST similarly be sent twice, with L flag clear and set. + Multiple changed routes MAY be grouped into a single BGP UPDATE PDU + when feasible, exactly as in the standard BGP protocol. + + + + +Scudder, et al. Standards Track [Page 18] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + It's important to note that RM messages are not replicated messages + received from a peer. (Route mirroring (Section 6) is provided if + this is required.) While the router should attempt to generate + updates promptly, there is a finite time that could elapse between + reception of an update, the generation an RM message, and its + transmission to the monitoring station. If there are state changes + in the interim for that prefix, it is acceptable that the router + generate the final state of that prefix to the monitoring station. + This is sometimes known as "state compression". The actual PDU + generated and transmitted to the station might also differ from the + exact PDU received from the peer, for example, due to differences + between how different implementations format path attributes. + +6. Route Mirroring + + Route Mirroring messages are provided for two primary reasons: First, + to enable an implementation to operate in a mode where it provides a + full-fidelity view of all messages received from its peers, without + state compression. As we note in Section 5, BMP's normal operational + mode cannot provide this. Implementors are strongly cautioned that + without state compression, an implementation could require unbounded + storage to buffer messages queued to be mirrored. Route Mirroring is + unlikely to be suitable for implementation in conventional routers, + and its use is NOT RECOMMENDED except in cases where implementors + have carefully considered the tradeoffs. These tradeoffs include: + router resource exhaustion, the potential to interfere with the + transmission or reception of BGP UPDATE messages, and the slowing of + routing convergence. + + The second application for Route Mirroring is for error reporting and + diagnosis. When Revised Error Handling for BGP UPDATE messages + [RFC7606] is in use, a router can process BGP messages that are + determined to contain errors, without resetting the BGP session. + Such messages MAY be mirrored. The buffering used for such mirroring + SHOULD be limited. If an errored message is unable to be mirrored + due to buffer exhaustion, a message with the "Messages Lost" code + SHOULD be sent to indicate this. (This implies that a buffer should + be reserved for this use.) + +7. Stat Reports + + As outlined above, SR messages are used to monitor specific events + and counters on the monitored router. One type of monitoring could + be to find out if there are an undue number of route advertisements + and withdraws happening (churn) on the monitored router. Another + metric is to evaluate the number of looped AS_PATHs on the router. + + + + + +Scudder, et al. Standards Track [Page 19] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + While this document proposes a small set of counters to begin with, + the authors envision that this list may grow in the future with new + applications that require BMP-style monitoring. + +8. Other Considerations + +8.1. Multiple Instances + + Some routers may support multiple instances of the BGP protocol, for + example, as "logical routers" or through some other facility. The + BMP protocol relates to a single instance of BGP; thus, if a router + supports multiple BGP instances it should also support multiple BMP + instances (one per BGP instance). Different BMP instances SHOULD + generate Initiation Messages that are distinct from one another, for + example, by using distinguishable sysNames or by the inclusion of + instance-identifying information in a string TLV. + +8.2. Locally Originated Routes + + Some consideration is required for routes originated into BGP by the + local router, whether as a result of redistribution from another + protocol or for some other reason. + + Such routes can be modeled as having been sent by the router to + itself, placing the router's own address in the Peer Address field of + the header. It is RECOMMENDED that when doing so, the router should + use the same address it has used as its local address for the BMP + session. Since in this case no transport session actually exists, + the Local and Remote Port fields of the Peer Up message MUST be set + to 0. Clearly, the OPEN Message fields of the Peer Up message will + equally not have been transmitted physically, but should represent + the relevant capabilities of the local router. + + Also, recall that the L flag is used to indicate locally sourced + routes, see Section 4.2. + +9. Using BMP + + Once the BMP session is established, route monitoring starts dumping + the current snapshot as well as incremental changes simultaneously. + + It is fine to have these operations occur concurrently. If the + initial dump visits a route and subsequently a withdraw is received, + this will be forwarded to the monitoring station that would have to + correlate and reflect the deletion of that route in its internal + state. This is an operation that a monitoring station would need to + support, regardless. + + + + +Scudder, et al. Standards Track [Page 20] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + If the router receives a withdraw for a prefix even before the peer + dump procedure visits that prefix, then the router would clean up + that route from its internal state and will not forward it to the + monitoring station. In this case, the monitoring station may receive + a bogus withdraw it can safely ignore. + +10. IANA Considerations + + IANA has created registries for the following BMP parameters, which + are organized in a new group "BGP Monitoring Protocol (BMP) + Parameters". + +10.1. BMP Message Types + + This document defines seven message types for transferring BGP + messages between cooperating systems (Section 4): + + o Type 0: Route Monitoring + o Type 1: Statistics Report + o Type 2: Peer Down Notification + o Type 3: Peer Up Notification + o Type 4: Initiation + o Type 5: Termination + o Type 6: Route Mirroring + + Type values 0 through 127 MUST be assigned using the "Standards + Action" policy, and values 128 through 250 using the "Specification + Required" policy defined in [RFC5226]. Values 251 through 254 are + Experimental, and value 255 is Reserved. + +10.2. BMP Peer Types + + This document defines three types of peers for purposes of + interpreting the Peer Distinguisher field (Section 4.2): + + o Peer Type = 0: Global Instance Peer + o Peer Type = 1: RD Instance Peer + o Peer Type = 2: Local Instance Peer + + Peer Type values 0 through 127 MUST be assigned using the "Standards + Action" policy, and values 128 through 250 using the "Specification + Required" policy, defined in [RFC5226]. Values 251 through 254 are + Experimental, and value 255 is Reserved. + + + + + + + + +Scudder, et al. Standards Track [Page 21] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +10.3. BMP Peer Flags + + This document defines three bit flags in the Peer Flags field of the + per-peer header (Section 4.2). The bits are numbered from 0 (the + high-order, or leftmost, bit) to 7 (the low-order, or rightmost, + bit): + + o Flag 0: V flag + o Flag 1: L flag + o Flag 2: A flag + + Flags 3 through 7 are unassigned. The registration procedure for the + registry is "Standards Action". + +10.4. BMP Statistics Types + + This document defines fourteen statistics types for statistics + reporting (Section 4.8): + + o Stat Type = 0: Number of prefixes rejected by inbound policy + o Stat Type = 1: Number of (known) duplicate prefix advertisements + o Stat Type = 2: Number of (known) duplicate withdraws + o Stat Type = 3: Number of updates invalidated due to CLUSTER_LIST + loop + o Stat Type = 4: Number of updates invalidated due to AS_PATH loop + o Stat Type = 5: Number of updates invalidated due to ORIGINATOR_ID + o Stat Type = 6: Number of updates invalidated due to a loop found + in AS_CONFED_SEQUENCE or AS_CONFED_SET + o Stat Type = 7: Number of routes in Adj-RIBs-In + o Stat Type = 8: Number of routes in Loc-RIB + o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In + o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB + o Stat Type = 11: Number of updates subjected to treat-as-withdraw + o Stat Type = 12: Number of prefixes subjected to treat-as-withdraw + o Stat Type = 13: Number of duplicate update messages received + + Stat Type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is Reserved. + + + + + + + + + + + +Scudder, et al. Standards Track [Page 22] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +10.5. BMP Initiation Message TLVs + + This document defines three types for information carried in the + Initiation message (Section 4.3): + + o Type = 0: String + o Type = 1: sysDescr + o Type = 2: sysName + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is reserved. + +10.6. BMP Termination Message TLVs + + This document defines two types for information carried in the + Termination message (Section 4.5): + + o Type = 0: String + o Type = 1: Reason + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is Reserved. + +10.7. BMP Termination Message Reason Codes + + This document defines five types for information carried in the + Termination message (Section 4.5) Reason code: + + o Type = 0: Administratively closed + o Type = 1: Unspecified reason + o Type = 2: Out of resources + o Type = 3: Redundant connection + o Type = 4: Permanently administratively closed + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is Reserved. + + + + + + + + + +Scudder, et al. Standards Track [Page 23] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +10.8. BMP Peer Down Reason Codes + + This document defines five types for information carried in the Peer + Down Notification (Section 4.9) Reason code (and reserves one further + type): + + o Type = 0 is Reserved. + o Type = 1: Local system closed, NOTIFICATION PDU follows + o Type = 2: Local system closed, FSM Event follows + o Type = 3: Remote system closed, NOTIFICATION PDU follows + o Type = 4: Remote system closed, no data + o Type = 5: Peer de-configured + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and values 0 and 65535 are Reserved. + +10.9. Route Mirroring TLVs + + This document defines two types for information carried in the Route + Mirroring message (Section 4.7): + + o Type = 0: BGP Message + o Type = 1: Information + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is Reserved. + +10.10. BMP Route Mirroring Information Codes + + This document defines two types for information carried in the Route + Mirroring Information (Section 4.7) code: + + o Type = 0: Errored PDU + o Type = 1: Messages Lost + + Information type values 0 through 32767 MUST be assigned using the + "Standards Action" policy, and values 32768 through 65530 using the + "Specification Required" policy, defined in [RFC5226]. Values 65531 + through 65534 are Experimental, and value 65535 is Reserved. + + + + + + + + +Scudder, et al. Standards Track [Page 24] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +11. Security Considerations + + This document defines a mechanism to obtain a full dump or provide + continuous monitoring of a BGP speaker's BGP routes, including + received BGP messages. This capability could allow an outside party + to obtain information not otherwise obtainable. For example, + although it's hard to consider the content of BGP routes in the + public Internet to be confidential, BGP is used in private contexts + as well, for example, for L3VPN [RFC4364]. As another example, a + clever attacker might be able to infer the content of the monitored + router's import policy by comparing the pre-policy routes exposed by + BMP, to post-policy routes exported in BGP. + + Implementations of this protocol SHOULD require manual configuration + of the monitored and monitoring devices. + + Unless a transport that provides mutual authentication is used, an + attacker could masquerade as the monitored router and trick a + monitoring station into accepting false information, or they could + masquerade as a monitoring station and gain unauthorized access to + BMP data. Unless a transport that provides confidentiality is used, + a passive or active attacker could gain access to, or tamper with, + the BMP data in flight. + + Where the security considerations outlined above are a concern, users + of this protocol should use IPsec [RFC4303] in tunnel mode with pre- + shared keys. + +12. References + +12.1. Normative References + + [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base + for Network Management of TCP/IP-based internets: MIB-II", + STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, + <http://www.rfc-editor.org/info/rfc1213>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <http://www.rfc-editor.org/info/rfc4271>. + + + + + +Scudder, et al. Standards Track [Page 25] + +RFC 7854 BGP Monitoring Protocol June 2016 + + + [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. + Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, + DOI 10.17487/RFC4724, January 2007, + <http://www.rfc-editor.org/info/rfc4724>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + <http://www.rfc-editor.org/info/rfc6793>. + + [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. + Patel, "Revised Error Handling for BGP UPDATE Messages", + RFC 7606, DOI 10.17487/RFC7606, August 2015, + <http://www.rfc-editor.org/info/rfc7606>. + +12.2. Informative References + + [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification + of management information for TCP/IP-based internets", + STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, + <http://www.rfc-editor.org/info/rfc1155>. + + [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual + Conventions for Additional High Capacity Data Types", + RFC 2856, DOI 10.17487/RFC2856, June 2000, + <http://www.rfc-editor.org/info/rfc2856>. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + <http://www.rfc-editor.org/info/rfc4303>. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February + 2006, <http://www.rfc-editor.org/info/rfc4364>. + + + + + + + + + + + + +Scudder, et al. Standards Track [Page 26] + +RFC 7854 BGP Monitoring Protocol June 2016 + + +Acknowledgements + + Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, + Pierre Francois, Jeffrey Haas, John Ioannidis, John Kemp, Mack + McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom + Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker, and the members + of the GROW working group for their comments. + +Authors' Addresses + + John Scudder (editor) + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + United States + + Email: jgs@juniper.net + + + Rex Fernando + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + United States + + Email: rex@cisco.com + + + Stephen Stuart + Google + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States + + Email: sstuart@google.com + + + + + + + + + + + + + + + + +Scudder, et al. Standards Track [Page 27] + |