Checking for Bogons

Checking for Bogons

[Gisle Vanem]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

Hello list.

I want to check if the result from 'loc_database_lookup()'
is on a "Bogon network".

My C-code would go something like:
   struct loc_network *net;
   struct in6_addr     addr;
   ...
   int rc = loc_database_lookup (libloc.db, &addr, &net);

   if (rc == 0 && net)
   {
     ...
     if (loc_network_has_flag(net, LOC_NETWORK_FLAG_BOGON))
        ...
   }
-----------------

This flag 'LOC_NETWORK_FLAG_BOGON' does not exist (yet).
Would it be possible?

And is there any relationship between a "Bogon" and
'LOC_NETWORK_FLAG_DROP' flag?

So I guess I have to do what:
   Database_iterate_all(self, LOC_DB_ENUMERATE_BOGONS, family, 0);

does and create my own list to check against (?)

And BTW, I'm on Windows-10.

-- 
--gv

Re: Checking for Bogons

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hello Gisle,

thanks for your mail.

> This flag 'LOC_NETWORK_FLAG_BOGON' does not exist (yet).
> Would it be possible? 

In theory, yes, but there is no need for another flag: If there is
is no announcement for a network, it is considered to be a bogon.

So, all you need to do is to check if loc_database_lookup() gives
you an ASN for the queried IP address. :-)

> And is there any relationship between a "Bogon" and
> 'LOC_NETWORK_FLAG_DROP' flag? 

Not really. Some bogons might get that flag as well, if they appear
at Spamhaus DROP (which will be our primary source for LOC_NETWORK_FLAG_DROP);
see https://www.spamhaus.org/sbl/query/SBL504836 for an example.

So, there might be some overlap in practice, but these are not 
inherently related to each other.

Thanks, and best regards,
Peter Müller

Re: Checking for Bogons

[Gisle Vanem]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

Peter Müller wrote:

>> This flag 'LOC_NETWORK_FLAG_BOGON' does not exist (yet).
>> Would it be possible?
> 
> In theory, yes, but there is no need for another flag: If there is
> is no announcement for a network, it is considered to be a bogon.

What do you mean by "no announcement for a network" exactly?
(kind of an alien term to me).

> So, all you need to do is to check if loc_database_lookup() gives
> you an ASN for the queried IP address. :-)

So no ASN result, means a "Bogon"?
A command like:
   location.py list-bogons --family ipv4

returns for example '1.236.0.0/18'. And
'location.py lookup ::ffff:1.236.0.0' returns an ASN:
   Network                 : 1.236.0.0/24
   Country                 : Korea, Republic of
   Autonomous System       : AS38396 - Paju office of Education Gyeonggi Province

Doesn't look like a "Bogon" to me.

And trying a 'nmap -sA -p80 1.236.0.0/24', gave me 11 hosts up.
Seems no router cares about Bogons.

> Thanks, and best regards,
> Peter Müller

Thanks for your answer.


-- 
--gv

Re: Checking for Bogons

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

Hello Gisle,

thanks for your reply.

> What do you mean by "no announcement for a network" exactly?
> (kind of an alien term to me). 

I meant a BGP announcement, such as this one:

> [root(a)maverick ~]# location lookup 193.0.6.139
> 193.0.6.139:
>   Network                 : 193.0.0.0/21
>   Country                 : Netherlands
>   Autonomous System       : AS3333 - Reseaux IP Europeens Network Coordination Centre (RIPE NCC)        <<<<<

> So no ASN result, means a "Bogon"? 

Yes.

> A command like:
>   location.py list-bogons --family ipv4
> 
> returns for example '1.236.0.0/18'. And
> 'location.py lookup ::ffff:1.236.0.0' returns an ASN:
>   Network                 : 1.236.0.0/24
>   Country                 : Korea, Republic of
>   Autonomous System       : AS38396 - Paju office of Education Gyeonggi Province
> 
> Doesn't look like a "Bogon" to me.
> 
> And trying a 'nmap -sA -p80 1.236.0.0/24', gave me 11 hosts up.
> Seems no router cares about Bogons. 

Indeed, looks like this does not work properly. Bug #12712
(https://bugzilla.ipfire.org/show_bug.cgi?id=12712) has been raised for this.

Sorry to disappoint.

Thanks, and best regards,
Peter Müller