IPv4 and IPv6 hijacking by AS 6
AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks like I'm not alone. Does anyone have any contacts there, or know what might be going on? The number of prefixes they're currently advertising is tremendous. The phone numbers associated with AS6's RIR whois data are non-functional. I've sent emails to their contacts listed in RIR whois (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm not optimistic. If anyone is there who has any control over AS 6 or knows whom I can reach out to, please let me know. Thanks, Matt
On Thu, Apr 12, 2018 at 8:34 PM, Matt Harris <matt@netfire.net> wrote:
AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks like I'm not alone. Does anyone have any contacts there, or know what might be going on? The number of prefixes they're currently advertising is tremendous. The phone numbers associated with AS6's RIR whois data are non-functional. I've sent emails to their contacts listed in RIR whois (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm not optimistic.
I think that it's an issue. Perhaps, also consider filing a request here: https://www.arin.net/public/whoisinaccuracy/index.xhtml
If anyone is there who has any control over AS 6 or knows whom I can reach out to, please let me know.
Thanks, Matt
Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise). notify: ed.gienko@atos.net notify: charlie.molnar@atos.net changed: christophe.fraule@atos.net 20180117 #18:47:40Z On Thu, Apr 12, 2018, at 9:34 AM, Matt Harris wrote:
AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks like I'm not alone. Does anyone have any contacts there, or know what might be going on? The number of prefixes they're currently advertising is tremendous. The phone numbers associated with AS6's RIR whois data are non-functional. I've sent emails to their contacts listed in RIR whois (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm not optimistic.
If anyone is there who has any control over AS 6 or knows whom I can reach out to, please let me know.
Thanks, Matt
On Thu, Apr 12, 2018 at 12:05 PM, <lists@as23738.net> wrote:
Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise).
notify: ed.gienko@atos.net notify: charlie.molnar@atos.net changed: christophe.fraule@atos.net 20180117 #18:47:40Z
I'm now in touch with Christophe; it looks as though perhaps there's a separate, rogue AS 6 running around with a different set of peers/transits, as he was able to confirm that none of his gear is advertising these prefixes. Thanks, Matt
On Thu, 12 Apr 2018 at 11:52, Matt Harris <matt@netfire.net> wrote:
On Thu, Apr 12, 2018 at 12:05 PM, <lists@as23738.net> wrote:
Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise).
notify: ed.gienko@atos.net notify: charlie.molnar@atos.net changed: christophe.fraule@atos.net 20180117 #18:47:40Z
I'm now in touch with Christophe; it looks as though perhaps there's a separate, rogue AS 6 running around with a different set of peers/transits, as he was able to confirm that none of his gear is advertising these prefixes.
That is what I feared as well. It appears the single digit ASNs often fall victim of other people’s misconfigurations or malicious activities. Hard to separate the impersonator from the real autonomous system. Job
Similar for AS2. A view from Oregon Route-views for AS2 related paths: * 43.227.224.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 103.197.104.1 0 134708 6453 4755 133711 133711 133711 2 i * 212.66.96.126 0 20912 174 6453 4755 133711 133711 133711 2 i * 217.192.89.50 0 3303 6453 4755 133711 133711 133711 2 i * 203.62.252.83 0 1221 4637 6453 4755 133711 133711 133711 2 i * 43.227.225.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 103.197.104.1 0 134708 6453 4755 133711 133711 133711 2 i * 212.66.96.126 0 20912 174 6453 4755 133711 133711 133711 2 i * 217.192.89.50 0 3303 6453 4755 133711 133711 133711 2 i * 203.62.252.83 0 1221 4637 6453 4755 133711 133711 133711 2 i * 91.143.144.0/20 208.51.134.254 0 0 3549 3356 12389 41837 41837 2 i * 212.66.96.126 0 20912 1267 12389 41837 41837 2 i * 37.139.139.0 0 57866 6762 12389 41837 41837 2 i * 195.208.112.161 0 3277 3267 12389 41837 41837 2 i * 93.104.209.174 0 58901 51167 3356 12389 41837 41837 2 i * 193.0.0.56 0 3333 1103 12389 41837 41837 2 i * 103.63.234.0/24 208.51.134.254 0 0 3549 3356 2914 132602 58715 55406 2 134403 i * 212.66.96.126 0 20912 174 132602 58715 55406 2 65501 134403 i * 134.222.87.1 650 0 286 6762 132602 58715 55406 2 134403 i * 194.85.40.15 0 0 3267 174 132602 58715 55406 2 65501 134403 i * 12.0.1.63 0 7018 2914 132602 58715 55406 2 134403 i * 37.139.139.0 0 57866 6762 132602 58715 55406 2 134403 i (and lot more!) On Fri, Apr 13, 2018 at 12:31 AM, Job Snijders <job@instituut.net> wrote:
On Thu, 12 Apr 2018 at 11:52, Matt Harris <matt@netfire.net> wrote:
On Thu, Apr 12, 2018 at 12:05 PM, <lists@as23738.net> wrote:
Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise).
notify: ed.gienko@atos.net notify: charlie.molnar@atos.net changed: christophe.fraule@atos.net 20180117 #18:47:40Z
I'm now in touch with Christophe; it looks as though perhaps there's a separate, rogue AS 6 running around with a different set of peers/transits, as he was able to confirm that none of his gear is advertising these prefixes.
That is what I feared as well. It appears the single digit ASNs often fall victim of other people’s misconfigurations or malicious activities. Hard to separate the impersonator from the real autonomous system.
Job
-- Anurag Bhatia anuragbhatia.com
Anurag Bhatia <me@anuragbhatia.com> writes:
Similar for AS2.
I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs. Someone might have wrongly assumed that set as-path prepend 133711 133711 could be written shorter like set as-path prepend 133711 2 and there you go... Bjørn
Unfortunately, that's how it's done in route policy on XR, so people bouncing between flavors can easily make that mistake. On 4/13/18, 4:15 AM, "NANOG on behalf of Bjørn Mork" <nanog-bounces@nanog.org on behalf of bjorn@mork.no> wrote: Anurag Bhatia <me@anuragbhatia.com> writes: > Similar for AS2. I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs. Someone might have wrongly assumed that set as-path prepend 133711 133711 could be written shorter like set as-path prepend 133711 2 and there you go... Bjørn
On Fri, 13 Apr 2018, Bjørn Mork wrote:
Date: Fri, 13 Apr 2018 10:13:47 +0200 From: Bjørn Mork <bjorn@mork.no> To: Anurag Bhatia <me@anuragbhatia.com> Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: IPv4 and IPv6 hijacking by AS 6
Anurag Bhatia <me@anuragbhatia.com> writes:
Similar for AS2.
I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs.
Someone might have wrongly assumed that
set as-path prepend 133711 133711
could be written shorter like
set as-path prepend 133711 2
and there you go...
Yes, ASN2 sees about 1-4 configuration related "rogue" announcements per month. What is going on right now does not appear to be a small misconfiguration. The only route we (University of Delaware) are announcing w/ ASN2 is 128.4.0.0/16. Jason Jason Cash Deputy CIO University of Delaware cash@udel.edu 302-831-0461
Dear Jason, On Fri, Apr 13, 2018 at 02:17:47PM -0400, Jason S. Cash wrote:
Yes, ASN2 sees about 1-4 configuration related "rogue" announcements per month. What is going on right now does not appear to be a small misconfiguration.
The only route we (University of Delaware) are announcing w/ ASN2 is 128.4.0.0/16.
Is this actually causing your organisation issues in terms of reachability, or additional workload for staff, or is it just a strange artifact you've learned to live with? Kind regards, Job
I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs.
Someone might have wrongly assumed that
set as-path prepend 133711 133711
could be written shorter like
set as-path prepend 133711 2
and there you go...
for someone else's prefix?
On Fri, Apr 13, 2018 at 10:35 PM, Randy Bush <randy@psg.com> wrote:
I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs.
Someone might have wrongly assumed that
set as-path prepend 133711 133711
could be written shorter like
set as-path prepend 133711 2
and there you go...
for someone else's prefix?
Perhaps their policy is something like: "prepend all of transit-provider-1 prefixes by 2, their links are crappy today" followed by output policy: "permit all of my prefixes (matched by as-path-regex) and my customer prefixes (matched by community)" there's probably a bunch of ways this can go sideways, that's just one simple (and seen before) example.
Randy Bush <randy@psg.com> writes:
I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs.
Someone might have wrongly assumed that
set as-path prepend 133711 133711
could be written shorter like
set as-path prepend 133711 2
and there you go...
for someone else's prefix?
No, of course not. At least I have no reason to beliece so. I briefly looked at a couple of the examples Anurag posted. And for those, the next AS number in the path seemed consistent with the prefix owner: * 43.227.224.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 91.143.144.0/20 208.51.134.254 0 0 3549 3356 12389 41837 41837 2 i bjorn@miraculix:~$ whois 43.227.224.0/24 |grep origin origin: AS133711 origin: AS58965 bjorn@miraculix:~$ whois 91.143.144.0/20 |grep origin origin: AS41837 Bjørn
❦ 12 avril 2018 13:51 -0500, Matt Harris <matt@netfire.net> :
Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise).
notify: ed.gienko@atos.net notify: charlie.molnar@atos.net changed: christophe.fraule@atos.net 20180117 #18:47:40Z
I'm now in touch with Christophe; it looks as though perhaps there's a separate, rogue AS 6 running around with a different set of peers/transits, as he was able to confirm that none of his gear is advertising these prefixes.
Maybe AS6 is used internally by the next AS on the path? -- Choose variable names that won't be confused. - The Elements of Programming Style (Kernighan & Plauger)
On Apr 13, 2018, at 12:27 AM, Vincent Bernat <bernat@luffy.cx> wrote:
Maybe AS6 is used internally by the next AS on the path?
I've definitely seen (and sadly, interacted with) operators that solved their "why doesn't non-meshed iBGP do what I'm expecting" problems by simply using different low-numbered ASNs internally (1,2,3... 19) instead of proper private ASNs. Theo
participants (13)
-
Anurag Bhatia -
Bjørn Mork -
Christopher Morrow -
David Hubbard -
Jason S. Cash -
Job Snijders -
Job Snijders -
lists＠as23738.net -
Loganaden Velvindron -
Matt Harris -
Randy Bush -
Theodore Baschak -
Vincent Bernat