- Test - lists.nanog.org

Re: prefix hijack by ASN 8997
by Scott Weeks 23 Sep '08

23 Sep '08

--- tme(a)multicasttech.com wrote: From: Marshall Eubanks <tme(a)multicasttech.com> : You didn't specify the time zone you are in, : so I looked at +- 1 day around it. If the : hijack lasted 6 hours, we should have seen it. My apologies, I just used the time zone the tool (bgplay.routeviews.org/bgplay) was using when I said: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 I'm sure it was in GMT. Seeing the many responses, we now know something happened and it was only about 15 minutes in duration. bgplay shows the problem with the above data and I was just wondering if I was understanding the impact correctly: > If the above two are correct, would it be > correct to say only the downstream customers > of ASN 3267 were affected? I was not following the rules properly: never attribute to malice that which can be explained by human error. I thought there might be some testing-of-the-water in preparation for future 'events' and I guess I was starting to be trigger happy after all the talk about the new BGP attack. scott --- tme(a)multicasttech.com wrote: From: Marshall Eubanks <tme(a)multicasttech.com> To: surfer(a)mauigateway.com Cc: <nanog(a)merit.edu> Subject: Re: prefix hijack by ASN 8997 Date: Tue, 23 Sep 2008 07:51:36 -0400 On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote: > > > > I am hoping to confirm a short-duration prefix hijack of > 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North- > West Telecom" in Russia) in using ASN 3267 (Russian Federal > University Network) to advertise our space to ASN 3277 (Regional > University and Scientific Network (RUSNet) of North-Western and > Saint-Petersburg Area of Russia). > > Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", > put in prefix 72.234.0.0/15 and select the dates: > > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > If so, am I understanding it correctly if I say ASN 3267 saw a > shorter path from ASN 8997, so refused the proper announcement from > ASN 36149 (me) it normally hears from ASN 174 (Cogent). I cannot confirm that from the monitoring program at AS 16517 : [tme@lennon mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008 bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? You didn't specify the time zone you are in, so I looked at +- 1 day around it. If the hijack lasted 6 hours, we should have seen it. Regards Marshall > > > If the above two are correct, would it be correct to say only the > downstream customers of ASN 3267 were affected? > > scott >

2 1

Re: InterCage, Inc. (NOT Atrivo)
by Scott Weeks 23 Sep '08

23 Sep '08

--- jpleger(a)gmail.com wrote: I am sure if I looked into it more I could find some exploits related to the sites. ------------------------------------- "Why software piracy might actually be good for companies." Folks should clean their own house before pointing fingers at others... scott

16 28

comparison of hijack alert systems [was]: prefix hijack by ASN 8997
by Scott Weeks 23 Sep '08

23 Sep '08

On Mon, 22 Sep 2008, Scott Weeks wrote: > > I am hoping to confirm a short-duration prefix hijack <snip> --- hank(a)efes.iucc.ac.il wrote: From: Hank Nussbacher <hank(a)efes.iucc.ac.il> I too spotted this via PHAS for a large number of prefixes, but have not received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected with so many RRC boxes that RIPE RIS would have caught it. I had thought it was a false positive from PHAS but now that you and others have seen it - I guess it is for real. ---------------------------------------- It'd be very interesting to compare said systems using this event. I have not subscribed to MyASN or watchmy.net yet, so I can't do that. I do note, however, that PHAS took 4 hours and 20 minutes to email me, which is within the specs noted on their site. scott

1 0

duplicate packet
by chloe K 23 Sep '08

23 Sep '08

Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now!

10 10

Re: prefix hijack by ASN 8997
by Scott Weeks 23 Sep '08

23 Sep '08

----------Scott Weeks <surfer(a)mauigateway.com> wrote: ------- > I am hoping to confirm a short-duration prefix hijack <snip> ------------------------------------- --- christian(a)broknrobot.com wrote: ------- From: "Christian Koch" <christian(a)broknrobot.com> I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix ------------------------------------- At what time did you see it? scott

2 1

XO Outage
by Justin Sharp 22 Sep '08

22 Sep '08

We are seeing some issues w/ XO/Savvis peering.. Trace from XO to Savvis IP space (64.75.10.151) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. scrubbed 0.0% 6 0.6 0.5 0.4 0.6 0.1 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 6 1.3 1.3 1.2 1.4 0.1 3. ??? Trace from Savvis to XO IP space (65.44.114.97) 1. scrubbed 0.0% 38 0.4 0.4 0.3 0.5 0.1 2. 64.41.199.129 0.0% 37 1.0 24.0 0.6 330.2 80.4 3. hr1-ge-7-47.santaclarasc5.savvis.net 0.0% 37 0.7 1.4 0.6 27.3 4.4 4. er1-te-1-0-0.sanjose3equinix.savvis.net 0.0% 37 0.7 5.2 0.6 140.3 23.2 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net 2.7% 37 2.9 4.0 2.6 16.6 2.5 6. cr2-pos-0-0-3-3.dallas.savvis.net 0.0% 37 42.6 43.1 42.3 51.4 1.4 7. dpr1-ge-4-0-0.dallasequinix.savvis.net 0.0% 37 43.1 44.8 42.9 76.9 6.7 8. er1-te-2-1.dallasequinix.savvis.net 0.0% 37 43.3 49.2 42.8 233.6 31.6 9. 208.175.175.90 0.0% 37 43.0 42.8 42.6 43.6 0.2 10. 65.106.1.102 75.0% 37 43.5 46.5 43.4 62.9 6.3 11. 65.106.1.101 0.0% 37 43.4 47.8 43.2 112.3 12.5 12. 65.106.0.41 0.0% 37 57.5 65.1 57.1 177.3 21.0 13. 65.106.1.73 0.0% 37 57.4 66.5 57.1 162.1 24.2 14. ??? Trying to call into XO and they aren't even taking calls, they mention something about network issues in Spokane. Any ideas as to what is going on/ETA to fix? --Justin

4 4

favourite XFP supplier?
by Joe Abley 22 Sep '08

22 Sep '08

Hi all, Anybody have a preferred supplier for 10GE XFPs, multimode and singlemode? These are to be installed in Force10 and Juniper hardware in Toronto, so a Canadian supplier would be fabulous although I won't hold my breath. Joe

2 1

RE: hat tip to .gov hostmasters
by Robert Bonomi 22 Sep '08

22 Sep '08

> Subject: RE: hat tip to .gov hostmasters > Date: Mon, 22 Sep 2008 11:49:50 -0400 > From: "Keith Medcalf" <kmedcalf(a)dessus.com> > > If I cannot authenticate the data myself, then it is simply untrusted and u= > ntrustworthy -- exactly the same as it is now. "Speak for yourself, John" applies. In the real world, there are cases where data that one is unable to authenticate by ones self *is* treated as fully trusted. Because someone with the authority to declare it to be that, by fiat, has done so. There may be a common "chain of command", and someone higher in the chain has declared that various inferiors "shall"(i.e. 'must') trust the work of other inferiors within the organization, for example. Or, it may be a contractually-delegated trust. Or, any of a number of other possibilities. Admittedly, in any of those scenarios, the 'strength' of trust is somewhat weaker than if it was self-verified, but it _is_ "far above" your claim of 'untrusted and untrustworthy'. > The end-stage is secure only if at that stage you also set all DNS infrastr= > ucture to refuse to talk to any DNS client/server/resolver that DOES NOT va= > lidate and enforce DNSSEC. Up until that point in time, there is NO CHANGE= > in the security posture from what we have today with no DNSSEC whatsoever. FALSE TO FACT. One does not have a _guarantee_ of 'accurate' data without end-to-end enforcement, this is true. Even _with_ end-to-end DNSSEC enforcement, one does not have such a guarantee. All it accomplishes is to make the insertion of bogus data harder. Not 'impossible', just 'harder'. If a local non-DNSSEC resolver consults _only_ a DNSSEC-aware server on an immediately adjacent network, it takes only a moderate 'extension of trust' to (a) the local network operator, (b) the adjacent network operator, and (c) the DNSSEC-aware server operator, to have a "reasonable degree" of trust in the accuracy of the data the local reslover has. This 'trust' involves the physical integrity of the networks -- that a host on -those- networks will not be allowed to spoof a source address of the DNSSEC-aware server; and the use of ingress-filtering on _source_ addresses -- to prevent any 'external' network/machine from spoofing it either. Beyond that, it is just a matter of 'trusting' a proper implementation on the server itself. _IF_ the anti-spoofing provisions are in place, and 'downstream' (non-aware) DNS resolvers (which consult -only- the 'aware' server) are under the same administrative control as the DNSSEC-aware one, *THEN* there is zero effective difference in the trust level for an answer obtained from the 'non-aware' system as one obtained from the 'aware' one. > To hold forth otherwise is to participate in deliberate fraud and misrepres= > entation of material facts. This really sounds like someone who has a financial interest in promulgating FUD. <grin>

1 0

Re: Atrivo/Intercage: NO Upstream depeer
by Emil Kacperski 22 Sep '08

22 Sep '08

Hello, It's true that David from PIE disconnected our link approx 9pm or so yesterday. Things were going perfect, no complaints for a few weeks now. The only thing I believe is that NTT gave lots of pressure to PIE. For some unknown reason when I tried to reach out to the security guy at NTT he basically said our contract is with PIE. So in a time like this you really get to know who your friends are and who should be avoided. Onward and upward! What doesn't kill you only makes you stronger ;-). Just feel bad for the customers for which I am truly sorry for right now ;-(. Thanks! Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: emil(a)intercage.com Phone: 925-550-3947 ICQ: 23531098

4 3

Re: Atrivo/Intercage: NO Upstream depeer
by Russell Mitchell 21 Sep '08

21 Sep '08

Matt: I've already put this offer up. I'll be more then happy to meet up at our datacenter and take you through our space. What I find funny is, your the first one whom participated in the recent reports to actually take up and respond to us. I've emailed Garth and Jart, and both of them refused to respond. I emailed both of them requesting the same information they gave to Directi. If they were able to provide Directi with a list of 20,000+ domains from their control that were abusive, why can't they provide US directly with a single 1? Then, release a joint-statement talking about how the companies need to come together to combat the abusive activities across the net, yet when we extend our hand and open up our network, we don't even get a response! Directi went from being a "partner in crime" with us to being a great anti-abuse supporting company.. How can YOU claim that WE don't do anything, if you won't report your findings in the first place? Got recent stuff? Why are you willing to give it now that we're OFFLINE? What can we do about it NOW at this very minute? You tell me when your going to be in San Francisco, and I'll make myself available. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. P.S. I just realized all my responses to earlier people like Gadi and them were direct and not cc to NANOG. Will "Reply to all" now :) ----- Original Message ---- From: Matt Jonkman <jonkman(a)jonkmans.com> To: Russell Mitchell <russm2k8(a)yahoo.com> Cc: nanog(a)nanog.org Sent: Sunday, September 21, 2008 4:02:15 PM Subject: Re: Atrivo/Intercage: NO Upstream depeer Russell Mitchell wrote: > ----- > > Matt: > It's very sad that your PROUD of you contribution to the supposed "white paper" on our company. I'd like to know, was any of your "contribution" to the report altered, or mis-represented, or are you truly unaware of how false the information you provided was? > Care to have verified it? or are you a Spamhaus admin like John Reid who has that magic stick to make a claim and attack anyone who objects to it with the truth? I'd love to, but nanog isn't the place. I'll be in san fran in the near future. Lets sit down over a beer, I'll bring the research and you can look it over yourself. That would be far more productive than this. I think a few other folks would love to meet up with you as well. Maybe Emil can join us too? It's easy to insinuate from behind a keyboard. Lets get down to facts. But take this off nanog. This is NOT the place for it. Let me know when you'l be in town, I'll schedule my travel in that direction to meet up soon. Matt -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc

2 1