Re: Anyone notice strange announcements for 174.128.31.0/24
At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the Victim AS Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart pstew...@nexicomgroup.netwrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul -Original Message- From: Majdi S. Abbas [mailto:m...@latt.net] Sent: Monday, January 12, 2009 1:49 PM To: Michienne Dixon Cc: nanog@nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24? I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0 randy lied but no packets died enough now More seriously, this is indeed reachability research. Try emailing the AS 3130 contacts although I'd imagine Randy will see this. Thanks, --msa The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you.
Re: Prefix Hijack Tool Comaprision
Agreed. The Internet Alert Registry ( http://iar.cs.unm.edu ) has switched from monitoring RIPE and Routeviews to direct connections with our PGBGP enabled router. This means the IAR has less data, but immediate response times. Some of the prefixes were detected as hijacked by the IAR but most of the hijacked prefixes never reached the IAR's neighbors. If anyone would like to add their feed to the IAR we would appreciate it! Josh On Thu, Nov 13, 2008 at 2:31 PM, Mohit Lad [EMAIL PROTECTED] wrote: Sorry for the subject line in the previous message :-) Since this thread started as comparison of the tools, there are two issues 1. Which BGP feeds the tools use? RIPE, RouteViews, other private feeds. 2. How they decide what to send and what not to send? In this case, BGPMon detected an event that was not detected by others, and there might be other hijacks that were local in scope where PHAS or Watchmy might catch something that BGPMon does not. But that does not make one tool better than the other, unless this pattern is repeated. Eventually all tools will catch up with each other on the feeds (or so is the hope), so the difference will then lie in the decision of what to send and what to drop. Mohit Date: Thu, 13 Nov 2008 20:27:32 + From: Alexander Harrowell [EMAIL PROTECTED] Subject: Re: Prefix Hijack Tool Comaprision To: Todd Underwood [EMAIL PROTECTED] Cc: nanog@nanog.org OK. This seems to be a flaw in RIPE RIS, a pity because BGPlay is great. - original message - Subject:Re: Prefix Hijack Tool Comaprision From: Todd Underwood [EMAIL PROTECTED] Date: 13/11/2008 8:05 pm alexander, all, On Thu, Nov 13, 2008 at 07:56:26PM +, Alexander Harrowell wrote: It may be the North American NOG, but it's been said before that it functions as a GNOG, G for Global. I don't think Brazil is insignificant. I respect Todd's work greatly, but I think he's wrong on this point. you misread me. i did not say that brazil was insignificant. it's not. it has some of the fastest growing internet in latin america. i said that *this* hijacking took place in an insignificant corner of the internet. i mean this AS-map wise rather than geographically. this hijacking didn't even spread beyond one or two ASes, one of whom just happened to be a RIPE RIS peer. real hijackings leak into dozens or hundreds or thousands of ASNs. they spread far and wide. that's why people carry them out, when they do. this one was stopped in its tracks in a very small portion of one corner of the AS graph. as such, i don't count it as a hijacking or leak of any great significance and wouldn't want to alert anyone about it. that's why i recommend that prefix hijacking detection systems do thresholding of peers to prevent a single, rogue, unrepresentative peer from reporting a hijacking when none is really happening. others may have a different approach, but without thresholding prefix alert systems can be noisy and more trouble than they are worth. sorry if it appears that i was denegrating .br . i was not. t. -- _ todd underwood +1 603 643 9300 x101 renesys corporation [EMAIL PROTECTED] http://www.renesys.com/blog
Pretty Good BGP on Quagga
All, We just wanted to let you know that Pretty Good BGP (PGBGP) is now available for Quagga. The Internet Alert Registry (IAR) has been running it stably for a few months now and we wanted to open it up to early adopters. Overview: PGBGP is a distributed security mechanism for BGP that attempts to avoid prefix hijacks, sub-prefix hijacks, and spoofed paths. Each router individually computes its own idea of the origin ASes for each prefix based on the past few days of routing announcements. Routes for prefixes with new origin ASes are labeled as anomalous and are depreferenced for 24 hours, using the more trusted (stable) routes where possible. New links are also considered anomalous, as well as new sub-prefixes. New sub-prefixes are dealt with by choosing paths to the trusted less specific when possible for 24 hours. Opt-in emails are sent to operators to inform them of anomalies, to help them identify and fix the problem (if any) within the 24 hours. Hardware overhead: Running PGBGP requires roughly ~20MB of extra RAM. Adding additional BGP sessions does not significantly affect PGBGP memory usage. CPU requirements are minimal. Routing performance: Sometimes, PGBGP will select an inferior path in order to avoid an anomalous route. Our studies have shown that typically, anomalous routes are short lived (e.g. due to convergence churn). On the IAR, of the available 1,546,996 routes in the RIB, 5,111 of them are anomalous at the time of writing this email. There are corner cases in which PGBGP could cause loss of reachability, and they are discussed in the papers. Documentation, papers, links to NANOG presentations, and the patch itself are available at the project's webpage: http://cs.unm.edu/~karlinjf/pgbgp/ If you're interested in PGBGP or would like to help further BGP security research, please give it a try and let us know that you're running it. We'd be happy to entertain suggestions, discuss the protocol, and provide support. Thanks for your time, Josh
