[AusNOG] Urgent - Pacnet NOC contact (with BGP clue)

Sun Dec 12 08:22:59 EST 2010

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