--- 1/draft-ietf-grow-bmp-15.txt 2015-11-12 14:15:07.197828583 -0800 +++ 2/draft-ietf-grow-bmp-16.txt 2015-11-12 14:15:07.253829941 -0800 @@ -1,21 +1,21 @@ Network Working Group J. Scudder, Ed. Internet-Draft Juniper Networks Intended status: Standards Track R. Fernando -Expires: February 12, 2016 Cisco Systems +Expires: May 15, 2016 Cisco Systems S. Stuart Google - August 11, 2015 + November 12, 2015 BGP Monitoring Protocol - draft-ietf-grow-bmp-15 + draft-ietf-grow-bmp-16 Abstract This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to 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. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 12, 2016. + This Internet-Draft will expire on May 15, 2016. Copyright Notice Copyright (c) 2015 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 @@ -86,32 +86,34 @@ 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 - 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 - 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 - 10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 - 10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 - 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 - 10.7. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 22 - 10.8. BMP Route Mirroring Information Codes . . . . . . . . . 22 + 10.2. BMP Peer Types . . . . . . . . . . . . . . . . . . . . . 20 + 10.3. BMP Peer Flags . . . . . . . . . . . . . . . . . . . . . 20 + 10.4. BMP Statistics Types . . . . . . . . . . . . . . . . . . 21 + 10.5. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 + 10.6. BMP Termination Message TLVs . . . . . . . . . . . . . . 22 + 10.7. BMP Termination Message Reason Codes . . . . . . . . . . 22 + 10.8. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 + 10.9. Route Mirroring TLVs . . . . . . . . . . . . . . . . . . 23 + 10.10. BMP Route Mirroring Information Codes . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 13.2. Informative References . . . . . . . . . . . . . . . . . 24 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 13.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Many researchers and network operators wish to have access to the contents of routers' BGP 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 introduction of BMP, this @@ -175,25 +177,26 @@ 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 PDUs. 3.2. Connection Establishment and Termination BMP operates over TCP. All options are controlled by configuration - on the monitored router. No 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 zero) or - it MAY silently discard any data sent by the monitoring station. + 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 + zero) 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, 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, @@ -212,22 +215,21 @@ 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, optionally with a Termination - message. + 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 @@ -314,21 +316,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Peer Type (1 byte): Identifies the type of the peer. Currently two types of peers are identified, * Peer Type = 0: Global Instance Peer - * Peer Type = 1: L3 VPN 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 8 +-+-+-+-+-+-+-+-+ |V|L|A| Reserved| +-+-+-+-+-+-+-+-+ * The V flag indicates the the Peer address is an IPv6 address. @@ -343,30 +346,37 @@ * The A flag, if set to 1, indicates the message is formatted using the legacy two-byte AS_PATH format. If set to 0, the message is formatted using the four-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 four-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. + * The remaining bits are reserved for future use. They MUST be + transmitted as zero and their values MUST be ignored on + receipt. o Peer Distinguisher (8 bytes): Routers today can have multiple - instances (example L3VPNs). This field is present to distinguish - peers that belong to one address domain from the other. + instances (example: 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 "L3VPN Instance Peer", it is set to the - route distinguisher of the particular L3VPN instance the peer - belongs to. + 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 @@ -501,48 +511,51 @@ 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 mirroring of messages that have - been treated-as-withdraw [I-D.ietf-idr-error-handling], 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. + 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. 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 two-byte type code, a two-byte length field, and a variable-length value. Inclusion of any given TLV is OPTIONAL, however at least one TLV SHOULD be included, otherwise what's the point of 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 two-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 [I-D.ietf-idr-error-handling]. A BGP Message TLV MUST - also occur in the TLV list. + 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 @@ -627,24 +640,24 @@ o Stat Type = 9: Number of routes in per-AFI/SAFI Adj-RIB-In. The value is structured as: AFI (2 bytes), SAFI (1 byte), followed by a 64-bit Gauge. o Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value is structured as: AFI (2 bytes), SAFI (1 byte), followed by a 64-bit Gauge. o Stat Type = 11: (32-bit Counter) Number of updates subjected to - treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. + treat-as-withdraw treatment [RFC7606]. o Stat Type = 12: (32-bit Counter) Number of prefixes subjected to - treat-as-withdraw treatment [I-D.ietf-idr-error-handling]. + 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. @@ -807,27 +820,27 @@ 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 flow-block BGP peers, and the slowing of routing convergence. The second application for Route Mirroring is for error reporting and - diagnosis. When [I-D.ietf-idr-error-handling] 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 a buffer should be reserved for this use.) + diagnosis. When [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 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. While this document proposes a small set of counters to begin with, @@ -900,21 +913,49 @@ o Type 3: Peer Up Notification o Type 4: Initiation o Type 5: Termination o Type 6: Route Mirroring Type values 0 through 128 MUST be assigned using the "Standards Action" policy, and values 129 through 250 using the "Specification Required" policy defined in [RFC5226]. Values 251 through 254 are "Experimental" and value 255 is reserved. -10.2. BMP Statistics Types +10.2. BMP Peer Types + + This document defines two 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. + +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 zero (the + high-order, or leftmost, bit) to seven (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 MUST be assigned using the "Standards Action" + policy. + +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. @@ -927,95 +968,95 @@ 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. -10.3. BMP Initiation Message TLVs +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.4. BMP Termination Message TLVs +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.5. BMP Termination Message Reason Codes +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. -10.6. BMP Peer Down Reason Codes +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.7. Route Mirroring TLVs +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.8. BMP Route Mirroring Information Codes +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 @@ -1035,49 +1076,40 @@ 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 could masquerade as a monitoring station and gain unauthorized access to BMP data. Unless a transport that provides confidentiality is used, - a passive attacker could gain access to BMP data in flight. However, - BGP is not commonly deployed over a transport providing - confidentiality, so it's debatable whether it's crucial to provide - confidentiality once the data is propagated into BMP. + a passive or active attacker could gain access to or tamper with the + BMP data in flight. However, BGP is not commonly deployed over a + transport providing confidentiality, so it's debatable whether it's + crucial to provide confidentiality once the data is propagated into + BMP. - Where the security considerations outlined above are a concern, users - of this protocol should consider using some type of transport that - provides mutual authentication, data integrity and transport - protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If - confidentiality is considered a concern, a transport providing that - as well could be selected. + This document does not specify any security mechanism for BMP. 12. Acknowledgements Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, Pierre Francois, Jeffrey Haas, John ji 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. 13. References 13.1. Normative References - [I-D.ietf-idr-error-handling] - Chen, E., Scudder, J., Mohapatra, P., and K. Patel, - "Revised Error Handling for BGP UPDATE Messages", draft- - ietf-idr-error-handling-19 (work in progress), April 2015. - [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1094,44 +1126,41 @@ [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, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . + [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, + . + 13.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, . [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual Conventions for Additional High Capacity Data Types", RFC 2856, DOI 10.17487/RFC2856, June 2000, . - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, DOI 10.17487/RFC4303, December 2005, - . - [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . - [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP - Authentication Option", RFC 5925, DOI 10.17487/RFC5925, - June 2010, . - Appendix A. Changes Between BMP Versions 1 and 2 o Added Peer Up Message o Added L flag o Editorial changes Appendix B. Changes Between BMP Versions 2 and 3 o Added a 32-bit length field to the fixed header. o Clarified error handling.