Proposal of enhancement on the RIRs/NRO delegation File format/info
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
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@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
On Tue, Jun 2, 2020 at 10:53 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:
SGVsbG8gZXZlcnlvbmUKClAuUyAuOiBJIGFwb2xvZ2l6ZSwgYnV0IEkgd3JpdGUgZm9yIG11bHRp cGxlIGVtYWlsIGxpc3RzLCBwcmVjaXNlbHkgYmVjYXVzZQppdCBpcyBhIHRvcGljIHRoYXQgaW50 ZXJlc3RzIG11bHRpcGxlIHJlZ2lvbnMuClAuUy4yOiBUaGUgb2JqZWN0aXZlIGluIHRoaXMgcHJv cG9zYWwgaXMgdG8gbWFrZSBmZWFzaWJsZSB0aGUgY3JlYXRpb24gb2YKdmFsaWRhdGlvbiBtZWNo YW5pc21zIGZvciB0aGUgY3JlYXRpb24gb2YgSVJSIFJvdXRlIC8gUm91dGU2IE9iamVjdHMsCndp dGhvdXQgcmVxdWlyaW5nIGFueSB0eXBlIG9mIGNoYW5nZSBpbiB0aGUgcHJvdG9jb2xzIGN1cnJl bnRseSBpbiB1c2UuCkp1c3QgYWRqdXN0aW5nIHRoZSBpbmZvcm1hdGlvbiBhbHJlYWR5IHB1Ymxp YyBhbmQgYXZhaWxhYmxlLgoKCgpJIGFtIGZyb20gQnJhemlsLCBhbmQgUmVnaXN0cm8uQlIgKE5h dGlvbmFsIEludGVybmV0IFJlZ2lzdHJ5KSBwcm92aWRlcyBhCmZpbGVbMV0gb2YgZGVsZWdhdGlv bnMgaW4gYSBmb3JtYXQgc2xpZ2h0bHkgZGlmZmVyZW50IGZyb20gdGhlIG9mZmljaWFsIE5STwpm b3JtYXQgWzJdLgoKSW4gdGhlIGxpbmsgYmVsb3cgWzFdIGl0IGlzIHBvc3NpYmxlIHRvIHNlZSBh IGxpc3Qgd2l0aCBhbiB1bmVxdWl2b2NhbAphc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBBU04gYW5k IHRoZSBJUCBibG9jayBkZWxlZ2F0ZWQgdG8gdGhlIG93bmVyLgpbMV0gZnRwOi8vZnRwLnJlZ2lz dHJvLmJyL3B1Yi9udW1lcmFjYW8vb3JpZ2luL25pY2JyLWFzbi1ibGstbGF0ZXN0LnR4dApOb3Rl OiBSZWdpc3Ryby5CUiBkZWxlZ2F0aW9ucyBhcmUgYWxzbyBwdWJsaXNoZWQgaW4gdGhlIG9mZmlj aWFsIE5STwpmb3JtYXQsIGluY2x1ZGVkIGluIExBQ05JQydzIHB1YmxpYyBhcmNoaXZlIFszXSB0 byB3aGljaCBOSUMuQlIgaXMgbGlua2VkLgoKVGhpcyB1bmVxdWl2b2NhbCBsaW5rIGFsbG93cyB1 cyBhbiBleHRyYSBsYXllciBvZiB2YWxpZGF0aW9uIHdpdGggcmVzcGVjdAp0byBIaWphY2sgb2Yg cHJlZml4ZXMsIGFuZCBhbHNvIHRoZSBjcmVhdGlvbiBvZiBJTlZBTElEIFJvdXRlIC8gUm91dGU2 Cm9iamVjdHMgaW4gSVJSLgoKSW5zcGlyZWQgYnkgdGhpcyBmaWxlIGZvcm1hdFsxXSwgSSBkZWNp ZGVkIHRvIHRha2UgYSBjbG9zZXIgbG9vayBhdCB0aGUKb2ZmaWNpYWwgTlJPIGZvcm1hdC4KQXMg ZXhwZWN0ZWQsIEkgd2FzIGFibGUgdG8gZXN0YWJsaXNoIGEgbGluayBiZXR3ZWVuIHRoZSBPd25l ciBvZiB0aGUgQVNOLAphbmQgdGhlIE93bmVyIG9mIHRoZSBJUHY0IC8gSVB2Ni4gSG93ZXZlciwg dGhpcyBsaW5rIGlzIE5PVCB1bmFtYmlndW91cy4KClRoZSBhdHRyaWJ1dGUgdGhhdCBtYWtlcyB0 aGlzIGxpbmsgaXMgT3BhcXVlLUlEIGFuZCBpcyBkZXNjcmliZWQgb24gTlJPCm9maWNpYWwgZm9y bWF0IGZpbGVbMl0uClRoaXMgYXR0cmlidXRlIHJlZmVycmVkIHRvIGFuIG9yZ2FuaXphdGlvbiB0 aGF0IGhvbGRzIHNvbWUgdHlwZSBvZgpudW1lcmljYWwgcmVzb3VyY2Ugb24gdGhlIEludGVybmV0 LgoKSW4gOTAtOTUlIG9mIGNhc2VzLCB0aGUgQVNOIDwtPiBPcGFxdWVJRCA8LT4gSW5ldE51bSBs aW5rIGlzIGFzc2VydGl2ZS4KSG93ZXZlciwgdGhlcmUgYXJlIGNhc2VzIGluIHdoaWNoIHRoaXMg YXNzb2NpYXRpb24gaXMgbm90IHN1ZmZpY2llbnQgdG8gYmUKYXNzZXJ0aXZlLgoKQSkgRGVsZWdh dGlvbnMgb2YgSVB2NCBhbmQgLyBvciBJUHY2IGJsb2NrcyB0byBlbmQgdXNlcnMgd2l0aG91dCB0 aGUKZGVsZWdhdGlvbiBvZiBhbiBBU04gdG8gdGhhdCBpbnN0aXR1dGlvbi4KIC0gVGhlc2UgY2Fz ZXMgZG8gbm90IGFsbG93IGFuIGFzc2VydGl2ZSBsaW5rIGJldHdlZW4gQVNOIGFuZCBJUHY0IC8g SVB2NiwKc28gdGhleSBBUkUgTk9UIFRIRSBGT0NVUyBvZiBteSBhbmFseXNpcy4KCkIpIE9yZ2Fu aXphdGlvbnMgdGhhdCBvd24gbXVsdGlwbGUgc2V0cyBvZiBBU04gPC0+IEluZXROdW0uCiBCLjEg LSBUaGUgY2F1c2UgdGhhdCBJIGJlbGlldmUgdG8gYmUgdGhlIG1vc3QgY29tbW9uIGZvciB0aGlz IGlzIG1lcmdlcnMKYW5kIGFjcXVpc2l0aW9ucyBvZiBvcmdhbml6YXRpb25zLCB3aGVyZSBkZXNw aXRlIHRoYXQgT3BhcXVlSUQgcmVmZXJyaW5nIHRvCnRoZSBzYW1lIG9yZ2FuaXphdGlvbiAoQ05Q SiAvIEVJTiAvIFJVQyAvIEZpc2NhbCBOdW1iZXIpLCB0aGUgQVNOIHNldHMgPC0gPgpJbmV0TnVt IGFyZSBmcm9tIGRpZmZlcmVudCBTZXJ2aWNlIFByb3ZpZGVycyAoc29tZXRpbWVzIGV2ZW4gaW4K Z2VvZ3JhcGhpY2FsbHkgZGlmZmVyZW50IHJlZ2lvbnMpLgogQi4yIC0gQnV0IHRoZXJlIGFyZSBv dGhlciBleGFtcGxlcyBvZiB0aGlzLCBzdWNoIGFzIHRoZSBuZWVkIGZvciBzcGVjaWZpYwpzZWdt ZW50YXRpb24gb2YgbmV0d29ya3Mgd2l0aGluIHRoZSBzYW1lIG9yZ2FuaXphdGlvbi4KCkJ5IGNv bnN1bHRpbmcgaW4gdGhlIFdob2lzIGRhdGFiYXNlcyBzb21lIG9mIHRoZXNlIEFTTnMsIGl0IGlz IHBvc3NpYmxlIHRvCnZlcmlmeSB0aGF0IHRoZSBsaW5raW5nIGluZm9ybWF0aW9uIGJldHdlZW4g QXV0bnVtIDwtPiBJbmV0bnVtIGV4aXN0cwp3aXRoaW4gdGhlIHdob2lzIGRhdGFiYXNlcy4KCmZp c2NoZXItbWFjLTM6IH4gZmlzY2hlcmRvdWdsYXMgJCB3aG9pcyAtaCB3aG9pcy5sYWNuaWMubmV0 IEFTMjgwMDAgfCBncmVwCm51bToKYXV0LW51bTogQVMyODAwMAppbmV0bnVtOiAxNzkuMC4xNTYg LyAyMgppbmV0bnVtOiAyMDAuNy44NCAvIDIzCmluZXRudW06IDIwMDE6IDEzYzc6IDcwMDEgOjog LyA0OAoKClRoZSBzdWdnZXN0aW9uIGl0c2VsZjoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkluIHRo ZSBvZmZpY2lhbCBmb3JtYXQgb2YgdGhlIE5STyBbMl0sIHRoZSAiRXh0ZW5zaW9ucyIgY29sdW1u IHByb3ZpZGVzIGZvcgp0aGUgYWRkaXRpb24gb2YgZGF0YSB0aGF0IHdhcyBub3QgeWV0IGZvcmVz ZWVuLgpJbiB0aGlzIGNvbHVtbiwgaW4gdGhlIElQdjQgYW5kIElQdjYgcmVzb3VyY2UgbGluZXMs IGlmIHRoYXQgYmxvY2sgaXMKYXNzb2NpYXRlZCB3aXRoIGFueSBBU04sIGFkZCB0aGUgQVNOIHRv IHdoaWNoIHRoYXQgYmxvY2sgaXMgYXNzb2NpYXRlZC4KCgoKVGhlIHF1ZXN0aW9uczoKLS0tLS0t LS0tLS0tLQogLSBBbnkgY29uc2lkZXJhdGlvbiBhYm91dCB0aGF0PwogLSBXaGF0IGlzIHRoZSBw YXRoIHRvIHJlYWNoIHRoZSByaWdodCBwZXJzb25zIHRvIG1ha2UgYSBvZmZpY2lhbCBwcm9wb3Nh bD8KCgpQLlMuMzoKWWVzLCBJIGtub3cgdGhhdCB3ZSBoYXZlIGVudGVyZWQgdGhlIGVyYSBvZiBS UEtJLgpZZXMsIEkga25vdyB0aGF0IHByb2JhYmx5IGluIDUtNiB5ZWFycyB3ZSB3aWxsIGhhdmUg YW5vdGhlciA5MCUgb2YgREZaIGFzClZBTElELgpCdXQgSSBiZWxpZXZlIHRoYXQgc3VjaCBhbiBh Y3Rpb24gd291bGQgcmVxdWlyZSBtaW5pbWFsIGVmZm9ydCwgYW1wbGUKcmVzdWx0LCBhbmQgd291 bGQgYWxzbyBzZXJ2ZSBhcyBhbiBpbmNlbnRpdmUgZm9yIHRoZSBkaXZlcnNpZnlpbmcgT3duZXIg b2YKSVAgYmxvY2tzIHRvIG1vdmUgYW5kIGNyZWF0ZSB0aGVpciBST0FzLgoKCgpFeGFtcGxlcyBv ZiBvcmdhbml6YXRpb25zIHdpdGggbXVsdGlwbGUgc2V0cyBvZiBBdXROdW08LT5JbmV0TnVtOgpC LjEuYQogICJURUxFRsOUTklDQSBCUkFTSUwgUy5BIiB3aXRoIDkgQVNOcwogIDEwNDI5LCAxMTQx OSwgMTY4ODUsIDE2OTExLCAxODg4MSwgMTkxODIsIDIyMDkyLCAyNjU5OSwgMjc2OTkuCkIuMS5i CiAgIlRlbGVjb20gQXJnZW50aW5hIFMuQS4iIHdpdGggMTEgQVNOcwogIDczMDMsIDc5MzQsIDEw MzE4LCAxMDQ4MSwgMTA4OTUsIDEwOTgzLCAxMTM1NiwgMTIyNjQsIDIxNTkwLCAyNjYwOCwgMjc4 NzEuCkIuMi5hCiAgIk7DumNsZW8gZGUgSW5mLiBFIENvb3JkLiBEbyBQb250byBCUiAtIE5JQy5C UiIgd2l0aCAxNiBBU05zCiAgMTA5MDYsIDExMjg0LCAxMTQzMSwgMTE2NDQsIDExNzUyLCAxMjEz NiwgMTM4NzQsIDE0MDI2LCAxNDY1MCwgMjAxMjEsCjIyNTQ4LCAyNjE2MiwgMjYzMDQ0LCAyODM0 NSwgNTMwMzUsIDYxNTgwLgpCLjIuYgogICJMQUNOSUMgLSBMYXRpbiBBbWVyaWNhbiBhbmQgQ2Fy aWJiZWFuIElQIGFkZHJlc3MiIHdpdGggNyBBU05zLgogIDI4MDAwLCAyODAwMSwgMjgwMDIsIDI4 MTE5LCA1MjIyNCwgMjY0ODQ1LCAyNjQ4NDYKCgoKWzJdIGh0dHBzOi8vd3d3Lm5yby5uZXQvd3At Y29udGVudC91cGxvYWRzL25yby1leHRlbmRlZC1zdGF0cy1yZWFkbWU1LnR4dApbM10gZnRwOi8v ZnRwLmxhY25pYy5uZXQvcHViL3N0YXRzL2xhY25pYy9kZWxlZ2F0ZWQtbGFjbmljLWV4dGVuZGVk LWxhdGVzdAoKLS0gCkRvdWdsYXMgRmVybmFuZG8gRmlzY2hlcgpFbmfCuiBkZSBDb250cm9sZSBl IEF1dG9tYcOnw6NvCi0tCmd0ZXIgbGlzdCAgICBodHRwczovL2VuZy5yZWdpc3Ryby5ici9tYWls bWFuL2xpc3RpbmZvL2d0ZXIK
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 AutNumInetNum: 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 -- gter list https://eng.registro.br/mailman/listinfo/gter
-- William Herrin bill@herrin.us https://bill.herrin.us/
participants (2)
-
Douglas Fischer -
William Herrin