[lacnog] [Email reenviado] - [GTER] Proposal of enhancement on the RIRs/NRO delegation File format/info

Douglas Fischer fischerdouglas en gmail.com
Mar Jun 2 14:50:38 GMT+3 2020 

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
--
gter list    https://eng.registro.br/mailman/listinfo/gter
eޯ*'xj%y#
k*ey隊Yb)"rmǢ+brZ)zɮةނ*'Nn7+ފ{ak,jXjțayjبjXjبgkayjبEh׿F{-ꮊ*^!jx{az趇(.\&-iا^wfږw*nnXjwZi^!╩E"Z*'jR'z^+-*kzƟW^*')~j%m'b}z{_~'"jSQ9+v"{azX
b+)"nWǞjXꮊjV"jب秶H֧v^ zWjםaz'z_~kznoq?jۖIZ-MבzEץzj)b{az߉ȚN~jاr[yا,  +)bq܆+0'!4F+%yu8bު诡ƥ)jYhˬjwk'ږ'Z*'+a)ymxi(~~,^j[(歊|U F{h׺r"Q"{)o+afԇ^r'^v-jGrZ,zhF}MDfDZ-y0jƛhzZnXbF޷^;	ޮ5ݶwaxޮbX+
9;jf.8^jkzZfzabH:jwb׬ry'5~'"jWf~)^8bm&}yhjz+ͫb{ajh,gʗ~{zjZ޲q'׫H=jǬHөj 2'znX+ǫ+jjǬ|!m+bxlr'y,zbzWjب jw,v".^u^bzjp6-bbbtzǜjǬv赩ejدzX#Z>^D4AN	D~lr+:,ڶ*'Z'm^l4޴ۦTyƮajzXhmazj,&ߢaȬz֜謊ب,ڶ*'^^zZZzhjg64E@+jSnH'zn~&v'z''>/׫&zئzǯzx aƥ'b}z{kzvmj{Wa.ry_)yȟgbzp,+a{azƦzjxjب{.ا)塢+j֛jǬazǀH"+)"nWmbH)ߢ*'mpy޶{{"uZmr7~+ݢ%j!+!"V''z4
ަ{jg`4)޶{׿tמhzm4?xzm4]4<Nب+lzWȞ^r&~jD1슉rnzkz^ib*'Zajz-_yȞb%i^ jwH>z.ǥwaj",ȚpZ 5]HhZhrHj(r&yzب'''^bvmVb^aimiz(hj߉Ț見az0Z秵v^z}!"IZm)')ejz-҇T!޶!jv*'‹v*ޚ)♩^}+޲mjwp]j[(y)z{b^v+ޮȟ);	ޮ=hrK-j/yraz*8ũ(~jxjب"ةMb'znZLB @H6tou׍}ׯ<^]|u_6m=nݻAմޕ(
z{b+aP6~ߍt_5ӏ5O=]=}uߞn^}nͻA٣\x*(>M  Q+aנ6tNo8^7]zu];^4ۭx6]nxnmN8ߞٲ-b	'	mu޲"H6M44o4m_ymۮ<㝺:m'޷)rz{hi?קull杙m߶~eirwZis^eiqmzw^vVzC%j^vvb^Iuਞ瀺&j-zbm?"nj)fjb?׫

Más información sobre la lista de distribución LACNOG