This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] routing resiliency survey
- Next message (by thread): [routing-wg] Weekly Routing Table Report
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrei Robachevsky
robachevsky at isoc.org
Tue Oct 2 15:45:31 CEST 2012
Colleagues, Last week at the Routing WG I made a short presentation about our effort to facilitate collection of some operational data related to routing resiliency. We are looking for some statistics and analysis from the NOC side. I understand there might be concerns regarding the disclosure of such information, but we hope we can figure out how to handle sensitivities, on a case by case basis. To give you a better idea of what I am talking about (and was talking about at RIPE65) I attach the survey itself. Please contact me if you are interested in taking part in this survey. I also appreciate any concrete suggestions regarding the questions or the survey in general. Regards, Andrei -- Andrei Robachevsky Technology Program Manager Internet Society www.isoc.org -------------- next part -------------- *Routing Resiliency Survey* *Intro* When addressing routing security issues, as with any security-related activity, a network operator needs factual data and a good understanding of what's going on in the system to better inform the process of risk assessment and the selection of adequate tools and approaches. It is also important to measure the effect of such tools once they are deployed, and monitor the changing dynamics of the environment. Because the inter-domain routing system is global, such monitoring and measurements should be long-term and be done on a global scale. In this context, one important data set is operational statistics of incidents related to routing security, as registered by a network operator. This survey is aimed at collecting these operational data. *Non-disclosure* We understand the sensitivity of some of these data, therefore, the Internet Society will follow a few rules when conducting this survey: - network operators are not asked to provide data that is strictly company confidential; - all requested data is in the form of statistical information and doesn't need to reveal specifics, like AS numbers, prefixes, etc. - even if such information is submitted for the discretion of the Internet Society, it will be fully anonymized before sharing with anyone, and presented in collated form. *Questions* 0. Please provide your AS number: [ ] 1. Please provide statistics on the number of registered incident (e.g. opened tickets) by your NOC over the past 6 months, related to route hijacking. In particular, addressing the following incidents: 1.1. One of your own prefixes is hijacked [ ] times in the past 6 months (please enter a number, approximations are fine) 1.2. A prefix of one of your customers is hijacked somewhere in the Internet [ ] times in the past 6 months (please enter a number, approximations are fine) 1.3. One of your (direct or indirect) customers hijacks a prefix of another of your customers [ ] times in the past 6 months (please enter a number, approximations are fine) 2. For each of these categories, please specify 2.1. Typical duration of the incidents Your prefix is hijacked: Your customer?s prefix is hijacked somewhere in the Internet: Customer hijacks prefix of another customer: 2.2. What are typical causes of the incidents (e.g. misconfiguration (please be more specific, if possible), malicious intent)? Your prefix is hijacked: Your customer?s prefix is hijacked somewhere in the Internet: Customer hijacks prefix of another customer: 2.3. What are typical measures that were taken to mitigate or resolve the incidents (e.g. closed mailinglists, IXP mailinglist, peer contacts, contacts from whois databases)? Your prefix is hijacked: Your customer?s prefix is hijacked somewhere in the Internet: Customer hijacks prefix of another customer: 3. If you use the following routing security controls, please provide an indication of how often the following exceptions are captured: 3.1. A number of prefixes received from a BGP neighbor exceeds the maximum-prefix limit 3.2. An update from a BGP neighbor is rejected due to violation of your routing policy - prefix origin violation - AS-PATH violation - prefix announcement violation (e.g. announcement of your peer networks by your customer) 3.3. Alerts received by routing monitoring tools (e.g. BGPmon)
- Next message (by thread): [routing-wg] Weekly Routing Table Report
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]