secure peering.

1. BGP Monitoring System (BGPMon) Yan Chen, He Yan, Dave Matthews, Dan Massey (Colorado State University) Lan Wang (University of Memphis) Lixia Zhang (UCLA) http://netsec.colostate.edu/bgpmonitor BGP Data Collection Main Challenges Our Solution • Improve the current infrastructure -- introduce fewer measurement artifacts (lack of reset messages, inability to clearly identify table transfers, peering session failures etc) • Scale the monitoring system -- be able to peer with more routers • Add real-time access to data over current delay of hours • Support for protocol changes and features -- secure peering, new BGP attributes, etc. • Better organize the resulting data for long term storage and ease of use by researchers • Design a lightweight software focus on accurately and reliably collecting and storing BGP data ( no forwarding tables, route announcements etc) • Provide chainable feature to support regional deployment and scalability • Allow users directly connect to system to get real-time data for specific peers and/or prefixes • Log data in an extendable and human-readable XML format to easily support new BGP attributes. • Label BGP data and organize it into a single file for each peer’s daily data to facilitate researcher. • BGP data is an essential resource for researchers and operators in Internet routing. • BGP data collection systems passively collect BGP data from Internet BGP routers. • BGP data collection system samples: RouteViews and RIPE. • 40 publications cite RouteViews [CiteSeer]. • 615 documents list RouteViews as references [Google Scholar]. • Hundreds of peers • Millions of updates per day per peer • More than 200,000 entries in each peer’s rib BGP data is large! AS AS AS BGP Peer Session AS AS updates BGP data Central Server ribs AS Users Collectors ISP BGP Routers Collection system: RouteViews/RIPE Data in XML BGPMon Architecture BGPMon Composition • <?xml version="1.0"?> • <bgp> • <message> • <time>2007-03-22T19:00:07Z</time> • <source_as>65001</source_as> • <source_ip>129.82.138.4</source_ip> • <destination_as>65009</destination_as> • <destination_ip>129.82.47.109</destination_ip> • <address_family>1</address_family> • <interface_index>0</interface_index> • <update> • <path_attributes> • <origin> • <transitive/> • <igp value='0'/> • </origin> • <as_path> • <transitive/> • <as_sequence>65001 14041 3356 22351 </as_sequence> • </as_path> • <next_hop> • <transitive/> • <value>129.82.138.4</value> • </next_hop> • </path_attributes> • <nlri> • <prefix label=“NANN”>82.206.163/24</prefix> • </nlri> • </update> • </message> Comparing the sizes of 15 minutes’ BGP updates in various formats • BGPMon functionalities: 1) collects ALL information receive from BGP routers by peering with them, 2) labels BGP updates, 3) provides customizable BGP data to end users or other BGPMons in XML format, and 4) periodically logs the data. • The system adopts a modular event-driven design; the data is shared among modules in a producer and consumer way. • The BGPMon is chainable: Each BGPMon can provide or send data to other BGPMons. • The root BGPMon is able to monitor large number of BGP routers through consolidating feeds from regions • Record data in a both human and machine readable format by increasing affordable storage space • XML is a common interface to other applications. Various existing tools can be used to process data. • Easy to add new feature by simply insert a new tag. a References • Address handling of RIB table contents when peer session lost. Ongoing and future work 1. RouteViews, http://www.routeviews.org/ 2. RIPE, http://www.ripe.net/ris 3. M. Welsh, D. Culler, and E. Brewer. SEDA: An Architecture for Well- Conditioned, Scalable Internet Services. In the Proceedings of the 18th Symposium on Operation Systems Principles, October 2001. • RIB table dump by attributes in order to save space. • Integrate with PHAS, share with NetViews team • secure peering.