[GTER] Proposal of enhancement on the RIRs/NRO delegation File format/info

Thu May 7 18:21:53 -03 2020

Talking to a friend, he suggested to map the specific ASNs in this
situation, and treat it separately.
Well, I don't think this is scalable...

Just to give you an idea of how big is this question, I have made some
scripts to count how much organizations exists with 1, 2, 3, and so ASNs
allocated.

Here goes(It is Scary!):

fischer-mac-3:~ fischerdouglas$ curl -R -O
https://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
 Current
                                 Dload  Upload   Total   Spent    Left
 Speed
100 41.6M  100 41.6M    0     0  1052k      0  0:00:40  0:00:40 --:--:--
1221k
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$ awk -F\| '{if($3=="asn" && $7=="assigned")
print $4,$8}' delegated-extended > NRO-ASNs.txt
fischer-mac-3:~ fischerdouglas$
fischer-mac-3:~ fischerdouglas$ awk '{ASNs[$2]++} END { for(Line in ASNs)
print ASNs[Line] }' NRO-ASNs.txt | awk '{h[$1]++} END { for(k in h) print
k, h[k] }' | sort -n
1 50627
2 3607
3 1155
4 517
5 321
6 169
7 123
8 99
9 50
10 50
11 48
12 35
13 23
14 23
15 25
16 21
17 26
18 12
19 15
20 15
21 20
22 10
23 14
24 11
25 6
26 8
27 9
28 7
29 6
30 6
31 7
32 5
33 4
34 8
35 5
36 3
37 5
38 1
39 5
40 5
41 3
42 3
43 1
44 1
45 3
46 3
47 1
49 2
50 2
51 1
52 1
53 1
54 1
55 1
56 4
57 3
58 2
60 1
61 2
64 1
66 1
68 1
69 1
71 1
72 2
76 3
77 1
78 1
79 1
80 2
81 2
84 2
88 1
91 1
92 1
94 2
95 1
99 1
100 1
102 1
105 1
109 1
111 1
114 1
116 1
119 1
121 1
124 1
136 1
143 1
151 2
152 1
162 1
169 1
218 1
220 1
238 1
300 1
355 1
384 1
457 1
473 1
481 1
502 1
604 1
fischer-mac-3:~ fischerdouglas$

Em qui., 7 de mai. de 2020 às 14:24, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> Hello everyone
>
> P.S .: I apologize, but I write for multiple email lists, precisely
> because it is a topic that interests multiple regions.
> P.S.2: The objective in this proposal is to make feasible the creation of
> validation mechanisms for the creation of IRR Route / Route6 Objects,
> without requiring any type of change in the protocols currently in use.
> Just adjusting the information already public and available.
>
>
>
> I am from Brazil, and Registro.BR (National Internet Registry) provides a
> file[1] of delegations in a format slightly different from the official NRO
> format [2].
>
> In the link below [1] it is possible to see a list with an unequivocal
> association between the ASN and the IP block delegated to the owner.
> [1] ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt
> Note: Registro.BR delegations are also published in the official NRO
> format, included in LACNIC's public archive [3] to which NIC.BR is linked.
>
> This unequivocal link allows us an extra layer of validation with respect
> to Hijack of prefixes, and also the creation of INVALID Route / Route6
> objects in IRR.
>
> Inspired by this file format[1], I decided to take a closer look at the
> official NRO format.
> As expected, I was able to establish a link between the Owner of the ASN,
> and the Owner of the IPv4 / IPv6. However, this link is NOT unambiguous.
>
> The attribute that makes this link is Opaque-ID and is described on NRO
> oficial format file[2].
> This attribute referred to an organization that holds some type of
> numerical resource on the Internet.
>
> In 90-95% of cases, the ASN <-> OpaqueID <-> InetNum link is assertive.
> However, there are cases in which this association is not sufficient to be
> assertive.
>
> A) Delegations of IPv4 and / or IPv6 blocks to end users without the
> delegation of an ASN to that institution.
>  - These cases do not allow an assertive link between ASN and IPv4 / IPv6,
> so they ARE NOT THE FOCUS of my analysis.
>
> B) Organizations that own multiple sets of ASN <-> InetNum.
>  B.1 - The cause that I believe to be the most common for this is mergers
> and acquisitions of organizations, where despite that OpaqueID referring to
> the same organization (CNPJ / EIN / RUC / Fiscal Number), the ASN sets <- >
> InetNum are from different Service Providers (sometimes even in
> geographically different regions).
>  B.2 - But there are other examples of this, such as the need for specific
> segmentation of networks within the same organization.
>
> By consulting in the Whois databases some of these ASNs, it is possible to
> verify that the linking information between Autnum <-> Inetnum exists
> within the whois databases.
>
> fischer-mac-3: ~ fischerdouglas $ whois -h whois.lacnic.net AS28000 |
> grep num:
> aut-num: AS28000
> inetnum: 179.0.156 / 22
> inetnum: 200.7.84 / 23
> inetnum: 2001: 13c7: 7001 :: / 48
>
>
> The suggestion itself:
> ---------------------
> In the official format of the NRO [2], the "Extensions" column provides
> for the addition of data that was not yet foreseen.
> In this column, in the IPv4 and IPv6 resource lines, if that block is
> associated with any ASN, add the ASN to which that block is associated.
>
>
>
> The questions:
> -------------
>  - Any consideration about that?
>  - What is the path to reach the right persons to make a official proposal?
>
>
> P.S.3:
> Yes, I know that we have entered the era of RPKI.
> Yes, I know that probably in 5-6 years we will have another 90% of DFZ as
> VALID.
> But I believe that such an action would require minimal effort, ample
> result, and would also serve as an incentive for the diversifying Owner of
> IP blocks to move and create their ROAs.
>
>
>
> Examples of organizations with multiple sets of AutNum<->InetNum:
> B.1.a
>   "TELEFÔNICA BRASIL S.A" with 9 ASNs
>   10429, 11419, 16885, 16911, 18881, 19182, 22092, 26599, 27699.
> B.1.b
>   "Telecom Argentina S.A." with 11 ASNs
>   7303, 7934, 10318, 10481, 10895, 10983, 11356, 12264, 21590, 26608,
> 27871.
> B.2.a
>   "Núcleo de Inf. E Coord. Do Ponto BR - NIC.BR" with 16 ASNs
>   10906, 11284, 11431, 11644, 11752, 12136, 13874, 14026, 14650, 20121,
> 22548, 26162, 263044, 28345, 53035, 61580.
> B.2.b
>   "LACNIC - Latin American and Caribbean IP address" with 7 ASNs.
>   28000, 28001, 28002, 28119, 52224, 264845, 264846
>
>
>
> [2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt
> [3] ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação