draft-ietf-grow-bmp-13.txt   draft-ietf-grow-bmp-14.txt 
Network Working Group J. Scudder, Ed. Network Working Group J. Scudder, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track R. Fernando Intended status: Standards Track R. Fernando
Expires: January 29, 2016 Cisco Systems Expires: February 8, 2016 Cisco Systems
S. Stuart S. Stuart
Google Google
July 28, 2015 August 7, 2015
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-13 draft-ietf-grow-bmp-14
Abstract Abstract
This document defines a protocol, BMP, that can be used to monitor This document defines a protocol, BMP, that can be used to monitor
BGP sessions. BMP is intended to provide a more convenient interface BGP sessions. BMP is intended to provide a convenient interface for
for obtaining route views for research purpose than the screen- obtaining route views. Prior to introduction of BMP, screen-scraping
scraping approach in common use today. The design goals are to keep was the most commonly-used approach to obtaining such views. The
BMP simple, useful, easily implemented, and minimally service- design goals are to keep BMP simple, useful, easily implemented, and
affecting. BMP is not suitable for use as a routing protocol. minimally service-affecting. BMP is not suitable for use as a
routing protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2016. This Internet-Draft will expire on February 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25 Appendix A. Changes Between BMP Versions 1 and 2 . . . . . . . . 25
Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25 Appendix B. Changes Between BMP Versions 2 and 3 . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many researchers wish to have access to the contents of routers' BGP Many researchers and network operators wish to have access to the
RIBs as well as a view of protocol updates the router is receiving. contents of routers' BGP RIBs as well as a view of protocol updates
This monitoring task cannot be realized by standard protocol the router is receiving. This monitoring task cannot be realized by
mechanisms. Prior to introduction of BMP, this data could only be standard protocol mechanisms. Prior to introduction of BMP, this
obtained through screen-scraping. data could only be obtained through screen-scraping.
The BMP protocol provides access to the Adj-RIB-In of a peer on an The BMP protocol provides access to the Adj-RIB-In of a peer on an
ongoing basis and a periodic dump of certain statistics the ongoing basis and a periodic dump of certain statistics the
monitoring station can use for further analysis. From a high level, monitoring station can use for further analysis. From a high level,
BMP can be thought of as the result of multiplexing together the BMP can be thought of as the result of multiplexing together the
messages received on the various monitored BGP sessions. messages received on the various monitored BGP sessions.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 11 skipping to change at page 7, line 11
o Message Type (1 byte): This identifies the type of the BMP o Message Type (1 byte): This identifies the type of the BMP
message. A BMP implementation MUST ignore unrecognized message message. A BMP implementation MUST ignore unrecognized message
types upon receipt. types upon receipt.
* Type = 0: Route Monitoring * Type = 0: Route Monitoring
* Type = 1: Statistics Report * Type = 1: Statistics Report
* Type = 2: Peer Down Notification * Type = 2: Peer Down Notification
* Type = 3: Peer Up Notification * Type = 3: Peer Up Notification
* Type = 4: Initiation Message * Type = 4: Initiation Message
* Type = 5: Termination Message * Type = 5: Termination Message
* Type = 6: Route Mirroring Message
4.2. Per-Peer Header 4.2. Per-Peer Header
The per-peer header follows the common header for most BMP messages. 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 The rest of the data in a BMP message is dependent on the "Message
Type" field in the common header. Type" field in the common header.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Type | Peer Flags | | Peer Type | Peer Flags |
skipping to change at page 20, line 16 skipping to change at page 20, line 16
IANA is requested to create registries for the following BMP IANA is requested to create registries for the following BMP
parameters, to be organized in a new group "BGP Monitoring Protocol parameters, to be organized in a new group "BGP Monitoring Protocol
(BMP) Parameters": (BMP) Parameters":
10.1. BMP Message Types 10.1. BMP Message Types
This document defines seven message types for transferring BGP This document defines seven message types for transferring BGP
messages between cooperating systems (Section 4): messages between cooperating systems (Section 4):
o Type 0: Route Monitor o Type 0: Route Monitoring
o Type 1: Statistics Report o Type 1: Statistics Report
o Type 2: Peer Down Notification o Type 2: Peer Down Notification
o Type 3: Peer Up Notification o Type 3: Peer Up Notification
o Type 4: Initiation o Type 4: Initiation
o Type 5: Termination o Type 5: Termination
o Type 6: Mirroring o Type 6: Route Mirroring
Type values 0 through 128 MUST be assigned using the "Standards Type values 0 through 128 MUST be assigned using the "Standards
Action" policy, and values 129 through 250 using the "Specification Action" policy, and values 129 through 250 using the "Specification
Required" policy defined in [RFC5226]. Values 251 through 254 are Required" policy defined in [RFC5226]. Values 251 through 254 are
"Experimental" and value 255 is reserved. "Experimental" and value 255 is reserved.
10.2. BMP Statistics Types 10.2. BMP Statistics Types
This document defines fourteen statistics types for statistics This document defines fourteen statistics types for statistics
reporting (Section 4.8): reporting (Section 4.8):
skipping to change at page 23, line 8 skipping to change at page 23, line 8
o Type = 1: Messages Lost. o Type = 1: Messages Lost.
Information type values 0 through 32767 MUST be assigned using the Information type values 0 through 32767 MUST be assigned using the
"Standards Action" policy, and values 32768 through 65530 using the "Standards Action" policy, and values 32768 through 65530 using the
"Specification Required" policy, defined in [RFC5226]. Values 65531 "Specification Required" policy, defined in [RFC5226]. Values 65531
through 65534 are "Experimental" and value 65535 is reserved. through 65534 are "Experimental" and value 65535 is reserved.
11. Security Considerations 11. Security Considerations
This document defines a mechanism to obtain a full dump or provide This document defines a mechanism to obtain a full dump or provide
continuous monitoring of a BGP speaker's local BGP table, including continuous monitoring of a BGP speaker's BGP routes, including
received BGP messages. This capability could allow an outside party received BGP messages. This capability could allow an outside party
to obtain information not otherwise obtainable. For example, to obtain information not otherwise obtainable. For example,
although it's hard to consider the content of BGP routes in the although it's hard to consider the content of BGP routes in the
public Internet to be confidential, BGP is used in private contexts public Internet to be confidential, BGP is used in private contexts
as well, for example for L3VPN [RFC4364]. As another example, a as well, for example for L3VPN [RFC4364]. As another example, a
clever attacker might be able to infer the content of the monitored clever attacker might be able to infer the content of the monitored
router's import policy by comparing the pre-policy routes exposed by router's import policy by comparing the pre-policy routes exposed by
BMP, to post-policy routes exported in BGP. BMP, to post-policy routes exported in BGP.
Implementations of this protocol MUST require manual configuration of Implementations of this protocol SHOULD require manual configuration
the monitored and monitoring devices. of the monitored and monitoring devices.
Unless a transport that provides mutual authentication is used, an Unless a transport that provides mutual authentication is used, an
attacker could masquerade as the monitored router and trick a attacker could masquerade as the monitored router and trick a
monitoring station into accepting false information, or could monitoring station into accepting false information, or could
masquerade as a monitoring station and gain unauthorized access to masquerade as a monitoring station and gain unauthorized access to
BMP data. Unless a transport that provides confidentiality is used, BMP data. Unless a transport that provides confidentiality is used,
a passive attacker could gain access to BMP data in flight. However, a passive attacker could gain access to BMP data in flight. However,
BGP is not commonly deployed over a transport providing BGP is not commonly deployed over a transport providing
confidentiality, so it's debatable whether it's crucial to provide confidentiality, so it's debatable whether it's crucial to provide
confidentiality once the data is propagated into BMP. confidentiality once the data is propagated into BMP.
Where the security considerations outlined above are a concern, users Where the security considerations outlined above are a concern, users
of this protocol should consider using some type of transport that of this protocol should consider using some type of transport that
provides mutual authentication, data integrity and transport provides mutual authentication, data integrity and transport
protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If
confidentiality is considered a concern, a transport providing that confidentiality is considered a concern, a transport providing that
as well could be selected. as well could be selected.
12. Acknowledgements 12. Acknowledgements
Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji Thanks to Ebben Aries, Michael Axelrod, Tim Evens, Pierre Francois,
Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack McBride, Danny
Dimitri Papadimitriou, Tom Petch, Robert Raszuk, Erik Romijn, and the McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch, Robert
members of the GROW working group for their comments. Raszuk, Erik Romijn, and the members of the GROW working group for
their comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-error-handling] [I-D.ietf-idr-error-handling]
Chen, E., Scudder, J., Mohapatra, P., and K. Patel, Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages", draft- "Revised Error Handling for BGP UPDATE Messages", draft-
ietf-idr-error-handling-19 (work in progress), April 2015. ietf-idr-error-handling-19 (work in progress), April 2015.
 End of changes. 12 change blocks. 
23 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/