[AusNOG] Urgent - Pacnet NOC contact (with BGP clue)
Skeeve Stevens
Skeeve at eintellego.net
Sun Dec 12 10:12:17 EST 2010
No Curtis went on to Blitz which bought Koala's remains and they went bust as well.
Then he went to AINS, and then he actually went to Alumina, my customer, who threw him out (for various reasons) and he went back to AINS... where he is now doing crap like this.
...Skeeve
--
Skeeve Stevens, CEO
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis
> -----Original Message-----
> From: Curtis Bayne [mailto:curtis at bayne.com.au]
> Sent: Sunday, 12 December 2010 8:23 AM
> To: Skeeve Stevens; Nick @ Deltaband; ausnog at lists.ausnog.net
> Subject: RE: [AusNOG] Urgent - Pacnet NOC contact (with BGP clue)
>
> The "other" Curtis... I thought this crap died with Koala back in 2007?
>
> Sent from my HTC Touch Pro
>
> -----Original Message-----
> From: Skeeve Stevens <Skeeve at eintellego.net>
> Sent: Sunday, 12 December 2010 12:42 AM
> To: Nick @ Deltaband <nick at deltaband.com>; ausnog at lists.ausnog.net
> <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Urgent - Pacnet NOC contact (with BGP clue)
>
> Hey Nick - thanks for that... useful.
>
> The AFP have talked to Curtis Raams from AINS and he is claiming he has
> a contractual right to poison a customer's routes in the global table
> if they haven't paid their bills. *blink* That is an interesting
> perspective. Commercial issues aside, no one should announce resources
> against the owners wishes.
>
> My opinion is that this is criminal activity and clearly falls under
> Denial of Service definition and since they've even admitted to the AFP
> that they are doing this on purpose, there is malice involved - they've
> put themselves in a big hole here. Pacnet by not doing anything, even
> after they have been informed, are also putting themselves at risk for
> essentially supporting their customers action by their lack of action.
>
> I definitely think that I need to come up with a policy submission at
> the next APNIC meeting in February which makes this matter extremely
> clear - that no one can announce resources in a malicious manner to
> deny the owner of those resources access to them.
>
> I wonder from an APNIC perspective that if a member acts like this,
> that there are some repercussions or something - like suspended
> membership, and so on available to APNIC as options. There has to be
> something that APNIC can do for this sort of situation, or this sort
> of thing will happen again and again and hostile entities will start
> crippling networks, and use providers like Pacnet to abuse the worlds
> routing tables.
>
> Thanks again goes out to the AFP for working hard on this... and APNIC
> for doing the right thing and getting involved. No thanks for Pacnet,
> who I once respected - for their lack of ability to realise what they
> were allowing their customer was doing was wrong.
>
> Ok... from a 'legalistic' perspective - given we're under APNIC which
> looks after many countries - where would what AINS are doing, be
> detailed in some way as 'against the rules' ? I assume it will be
> written somewhere under APNIC resources rules? Or somewhere else?
>
> It would help the AFP in this country to know what the position is, and
> also law enforcement organisations in other countries.
>
> In fact, perhaps it might be right to request APNIC to write up some
> sort of Law Enforcement Agency (LEA) guide when they have local
> disputes. I am just glad Pacnet have local representation, because
> what if this was an ISP in some other country - maybe not even English
> speaking, who was refusing? The AFP would have no power at that point I
> assume... so I guess APNIC has to step in somehow?
>
> Just some thoughts.
>
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> eintellego - The Experts that the Experts call
> - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis
>
> From: Nick @ Deltaband [mailto:nick at deltaband.com]
> Sent: Saturday, 11 December 2010 11:59 PM
> To: Skeeve Stevens; ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Urgent - Pacnet NOC contact (with BGP clue)
>
> Skeeve,
>
> From memory pacnet are big fans of the info in
> radb.net<http://radb.net> for filtering purposes... i was going to
> suggest updating your objects to reflect that pacnet's customer is no
> longer an upstream... but then i checked it:
>
> [root at vhost1 ~]# whois
> 180.189.136.0 at whois.radb.net<mailto:180.189.136.0 at whois.radb.net>
> [Querying whois.radb.net<http://whois.radb.net>]
> [whois.radb.net<http://whois.radb.net>]
> route: 180.189.136.0/22<http://180.189.136.0/22>
> descr: PACNET (proxy-registered route object)
> origin: AS45914
> remarks: This route object is for a PACNET customer route which is
> being exported under this origin AS.
> +
> This route object was created because no existing
> route
> object with the same origin was found, and since
> some
> ANC peers filter based on these objects this route
> may be rejected if this object is not created.
> +
> Please contact
> abuse at pacnet.net<mailto:abuse at pacnet.net> if you have any
> Concerns regarding Spam/Abuses related to this object
> +
> Please contact ip-noc at pacnet.net<mailto:ip-
> noc at pacnet.net> if you have any other
> Questions regarding this object.
> notify: ip-noc at pacnet.net<mailto:ip-noc at pacnet.net>
> mnt-by: MAINT-AS10026
> changed: ip-noc at pacnet.net<mailto:ip-noc at pacnet.net> 20100204
> source: RADB
> [root at vhost1 ~]# whois AS45914
> [Querying whois.radb.net<http://whois.radb.net>]
> [whois.radb.net<http://whois.radb.net>]
> aut-num: AS45914
> as-name: ALUMINA-NETWORKS-AS-AP
> descr: Alumina Networks Pty Ltd
> descr: Suite 1230, 1 Queens Road, Melbourne 3004
> country: AU
> admin-c: ANPL1-AP
> tech-c: ANPL1-AP
> mnt-routes: MAINT-ALUMINA-NETWORKS-AU
> mnt-by: MAINT-ALUMINA-NETWORKS-AU
> changed: hm-changed at apnic.net<mailto:hm-changed at apnic.net>
> 20090921
> source: APNIC
>
> Seems you might have to ask pacnet to update it as they created the
> objects on behalf of your client's old upstream.
>
> If the AFP don't give any joy perhaps an e-mail from Alumina, stating
> that as the origin AS for the above netblock (as per pacnet's own proxy
> registered object) you request they stop accepting the following route
> from their customer as they are falsely advertising the route with the
> origin as themselves (AS23871):
>
>
> BGP routing table entry for 180.189.136.0/24<http://180.189.136.0/24>,
> version 112823
>
> Paths: (2 available, best #1, table default)
>
> Not advertised to any peer
>
> 10026 23871
>
> 125.255.112.254 (metric 25) from 210.23.158.70 (210.23.158.70)
>
> Origin IGP, metric 0, localpref 400, valid, internal, best
>
> Community: 7543:1050 7543:1150 7543:1300 7543:1372 7543:2200
> 10026:4200 10026:33036 10026:40671
>
> 10026 23871
>
> 210.23.158.70 (metric 25) from 210.23.158.71 (210.23.158.71)
>
> Origin IGP, metric 0, localpref 400, valid, internal
>
> Community: 7543:1050 7543:1150 7543:1300 7543:1372 7543:2200
> 10026:4200 10026:33036 10026:40671
>
> Originator: 210.23.158.70, Cluster list: 210.23.158.71, 0.0.1.164
>
> Good luck.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Dec 11, 2010 at 10:02 PM, Skeeve Stevens
> <Skeeve at eintellego.net<mailto:Skeeve at eintellego.net>> wrote:
> The AFP is now involved - so let's see what happens now.
>
> I must say, the AFP agent understood exactly what the issue was, BGP
> and all. Very impressed.
>
>
> ...Skeeve (from the Gorillaz concert in Melbourne)
>
> --
> From the Blackberry Bold 9700 of Skeeve Stevens
>
> From: Matt Hope
> [mailto:matt.hope at nicta.com.au<mailto:matt.hope at nicta.com.au>]
> Sent: Saturday, December 11, 2010 09:51 PM
> To: ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>
> <ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>>
> Subject: Re: [AusNOG] Urgent - Pacnet NOC contact (with BGP clue)
>
>
> If you, or your customer is a AusCERT member, then this is likely
> something they can help with - if only to assist with legal
> proceedings.
>
> AusCERT do have a 24x7 members-only contact line, members can see the
> details here: https://www.auscert.org.au/render.html?it=5141
>
>
> - Matt
>
> On 10/12/10 19:59, Skeeve Stevens wrote:
> So, to update.
>
> After finally getting a Pacnet engineer who understood BGP and the
> issue (and was referring to my initial email to AusNOG), the engineer
> was instructed by his boss (don't have a name) to tell me to call
> APNIC.... but couldn't tell me what they expected APNIC to do.
>
> I informed the Pacnet engineer (Ramon) that if they keep allowing AINS
> to announce the ranges (see below) then they are party to the Denial of
> Service that is going on and in turn are committing a criminal act as
> well.
>
> Btw... the ranges I noted: 180.189.136.0/22<http://180.189.136.0/22>
> and 175.45.144.0/20<http://175.45.144.0/20> are being announced by AINS
> as /24's for maximum disruption effect.
>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
More information about the AusNOG
mailing list