BGP Hijack/Sickness with AS4637

Thu May 31 14:12:52 UTC 2018

     Well,

     None beside they're advertising a fake route of part of a MIT 
subnet using ASNs I care about.  (Which include GTT and MIT)

     Right now their getting it from their outfit in JP which do not 
have a LG, and we cannot find any other crumbs in most LG found on 
lookingglass.org.

     Without any cooperation from the only place we can see it, there 
isn't much we can do.

     PS; Might be a generational gap, but in the olden days we used to 
be able to get cooperation from other operators.

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 05/31/18 09:58, Phil Lavin wrote:
> What is the relationship of 103.97.52.2 (Colocation Australia - Japan) to you? Is this, for example, a peering over an IX? If so, did you learn the route from route servers or do you peer directly with them?
>
>
> Phil
>
> -----Original Message-----
> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Alain Hebert
> Sent: 31 May 2018 14:50
> To: nanog at nanog.org
> Subject: Re: BGP Hijack/Sickness with AS4637
>
>       Hi,
>
>       Well bad news on the ColoAU front, they refused to cooperate.
>
>       We'll pushback thru our GTT accounts...  But I'm running out of ideas.
>
>       If anyone has any good ideas how to proceed at this point feel free to share =D.
>
> -----
> Alain Hebert                                ahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>
> On 05/29/18 16:31, Chris Conn wrote:
>> Hello,
>>
>> I am the contact for AS16532.
>>
>> We never announced nor are we currently advertising this prefix as we
>> are not a transit AS for anyone.  As well, it seems to appear and
>> disappear from AS63956 looking glass.  According to that LG, the route
>> changed 6d ago, and is *still currently visible* at this very moment;
>>
>> https://lg.coloau.com.au/
>>
>> Command: show route 18.29.238.0 protocol bgp table
>> vrf-international.inet.0 active-path
>>
>> vrf-international.inet.0: 696764 destinations, 2288960 routes (696480
>> active, 0 holddown, 103994 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 18.29.238.0/23     *[BGP/170] 6d 01:06:11, localpref 90, from 103.97.52.2
>>                         AS path: 4637 3257 29909 16532 16532 16532
>> 16532 I, validation-state: unverified
>>
>>
>> AS16532 is not announcing this prefix.  We have a strict prefix-list that is applied to all sessions.  As well, AS29909 is filtering us using our announced AS-SETS/RPSL to avoid us the ability to do anything dumb.  And lastly, our announcements are being filtered by AS3257 as we are required to provide them via LOA.
>>
>> There is still something wrong somewhere that is injecting this path, anyone have a LG pointed to AS4637 seeing this prefix announced with AS16532 in the AS path?
>>
>> I doubt that AS29909 bouncing its BGP session with AS3257 (GTT) would
>> change anything, as I am not seeing this prefix in their route-server
>>
>> public at route-server.as3257.net-re0> show route 18.29.238.0 protocol
>> bgp active-path
>>
>> inet.0: 691667 destinations, 11752983 routes (691665 active, 1
>> holddown, 1 hidden)
>> + = Active Route, - = Last Active, * = Both
>>
>> 18.29.0.0/16       *[BGP/170] 3w4d 11:42:33, MED 0, localpref 100, from 213.200.87.23
>>                         AS path: 3257 174 3 I, validation-state: unverified
>>                       > to 141.136.111.13 via xe-1/0/0.0
>>
>> {master}
>> public at route-server.as3257.net-re0>
>>
>>
>> {master}
>> public at route-server.as3257.net-re0> show route 18.29.238.0 protocol
>> bgp | find 16532
>>
>> Pattern not found
>> {master}
>>
>>
>>
>> So whatever is happening, its not at AS16532, AS29909 nor AS3257 that I can find.
>>
>>
>> Chris Conn
>> AS16532
>>
>>
>>
>>
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Tom Paseka
>> via NANOG
>> Sent: Friday, May 25, 2018 6:01 PM
>> To: Nikolas Geyer <nik at neko.id.au>
>> Cc: NANOG list <nanog at nanog.org>
>> Subject: Re: BGP Hijack/Sickness with AS4637
>>
>> This looks like a route that has been cached by some ISPs/routers even though a withdrawal has actually happened.
>>
>> If you actually forward packets a long the path, you'll see its not following the AS Path suggested, instead the real route that it should be.
>> Bouncing your session with 4637 would likely clear this.
>>
>> -Tom
>>
>> On Fri, May 25, 2018 at 11:59 AM, Nikolas Geyer <nik at neko.id.au> wrote:
>>
>>> Greetings!
>>>
>>> Actually, what you have provided below shows the exact opposite. It
>>> shows ColoAU have received the route from 4637 who have received it
>>> from 3257 who have received it from 29909 who have received it from
>>> 16532 who originated it. It infers nothing about who 16532 found the route to come from.
>>>
>>> It is evident that GTT are advertising that route to Telstra Global
>>> :)
>>>
>>> Regards,
>>> Nik.
>>>
>>>>           And I'm pretty sure AS3257 (GTT ) is in the same boat as
>>>> us, as
>>> they're not the one advertising those routes to AS4637
>>>>       AS16532 found it to come from AS4637 as you can see from this
>>>> ColoAU
>>> LG output below
>>>> ----- https://lg.coloau.com.au/
>>>>
>>>> vrf-international.inet.0: 696533 destinations, 2248101 routes
>>>> (696249
>>> active, 0 holddown, 103835 hidden)
>>>> + = Active Route, - = Last Active, * = Both
>>>>
>>>> 18.29.238.0/23     *[BGP/170] 1d 19:57:28, localpref 90, from
>>> 103.97.52.2
>>>>                         AS path: 4637 3257 29909 16532 16532 16532
>>>> 16532
>>> I, validation-state: unverified
>>>> --
>>>> -----
>>>> Alain Hebert                                ahebert at pubnix.net
>>>> PubNIX Inc.
>>>> 50 boul. St-Charles
>>>> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
>>>> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>>>>