[GTER] Registro.BR non-compliant RFC9092 - Geolocalização IPs

[Douglas Fischer]

Falha minha e não ter ido buscar se existiam novas RFCs que falavam a
respeito desse tema.
Obrigado ao amigo que me alertou privadamente.

https://datatracker.ietf.org/doc/rfc9632/
Finding and Using Geofeed Data
Obsoletes RFC 9092

* RIPE has implemented the geofeed: attribute.
*  This document allows, but discourages, an inetnum: to have both
a geofeed remarks: attribute and a geofeed: attribute.
*  The Authentication section (Section 5) has been rewritten to be more
formal.
*  Geofeed files are only UTF-8 CSV.
*  This document stresses that authenticating geofeed data is optional.
*  IP Address Delegation extensions must not use "inherit".
*  If geofeed data are present, geographic location hints in other data
should be ignored.

Ainda não tive tempo de ler toda a RFC com a devida atenção.
Mas pelo que vi não existem mudanças significativas acerca do mecanismo de
publicação da URL de Geofeed.

Logo creio que a ideia proposta no e-mail de abertura desse thread pode ser
mantida.





Em seg., 20 de jan. de 2025 às 16:49, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> Olá a todos!
>
> Obs.: De antemão peço desculpas pelo cross-posting entre
>       listas de e-mail LACNOG e GTER(Brasil).
>
> Procuro os senhores para pedir que pensemos juntos em uma forma de ajudar
> a equipe do Registro.BR a tornar possível que os recursos de Whois/RDAP
> permitam que os Owners façam uso em cumprimento as RFCs 9092 e 8085.
>
>
> A RFC 9092 foi desenhada e aprovada justamente de uma maneira que permita
> os responsáveis por blocos IP fazerem declarações autoritativas referente a
> geolocalização sobre os conjuntos de IPs que estão sob sua
> responsabilidade. Lembrando que isso cabe em casos com um /22 IPv4 de uma
> alocação direta ou de um /29 IPv4 delegado.
> O que se faz é apontar no Whois/RDAP uma URL onde contenham entradas de
> geolocalização do referido bloco.
> Segundo a RFC isso pode ser feito através do atributo "remarks;" ou do
> novo atributo "geofeed:" que fora criado especialmente com esse propósito.
>
> Em todos os outros RIRs/NIRs é possível, com muita simplicidade, informar
> a URL do arquivo auto-publicado usando os "remarks:" de cada objeto inetnum
> e inet6num.
>
> No entanto, atualmente (e acho que desde sempre) o Registro.BR não permite
> que sejam adicionados "remarks;" no Whois/RDAP dos prefixos IPv4 e IPv6.O
> Registro.BR também não possui o atributo "geofeed:" disponível para ser
> alterado.
> E sendo assim, é impossível tecnicamente que um detentor de blocos IPv4 ou
> IPv6 possa definir as URLs de arquivo auto publicado de geolocalização de
> IPs.
>
> Eu não entendo o porquê o Registro.BR bloqueia o uso do atributo
> "remarks:" nos objetos de inetnum e inet6num. Esse seria o jeito mais
> simples e rápido de resolver essa questão.
> Quando levantei essa hipótese com pessoas de lá, percebi sinais extremos
> de "Esquece que isso nunca vai acontecer". Creio que possa estar
> relacionado a preocupações com mau uso do remarks para mensagens
> questionáveis como colocar um "remark: O Douglas é gordo e careca." Então,
> daqui de onde posso ver, imagino que a possibilidade essa a possibilidade
> de liberação do "remarks:" é quase nula.
> E com isso os detentores de recursos numéricos de IPv4 e IPv6 ainda seguem
> sem poder cumprir a RC9092.
>
> O meu pedido ao Registro.BR e um pouquinho de cronologia:
> 2013: Equipe do Google apresentou ao IETF a propostas sobre o geofeeds.csv
> Agosto de 2020: Publicada a RFC 8805 - A Format for Self-Published IP
> Geolocation Feeds
> Julho de 2021: Publicada a RFC 9092 - Finding and Using Geofeed Data
> Abril de 2022: Enviei contato à equipe do Registro.BR em questionamento
> sobre previsão de viabilizar os recursos para tornar possível o cumprimento
> da RFC 9092.
> Logo a seguir, a equipe do Registro.BR deu o ACK da solicitação,
> mencionando que iria encaminhar para área responsável (imagino ser setor de
> desenvolvimento de software).
> Desde então eu venho fazendo o que sou muito bom em fazer... Sendo chato,
> haha.
> Mas, pelo que pude entender, outras questões tomaram prioridade e essa
> questão acabou ficando de lado. E seguimos sem poder ficar em compliance
> com RFC9092.
>
>
> O pessoal da lista de e-mail do LACNOG deve estar pensando:
> "Tá bom Douglas, mas o que o LACNIC tem a ver com isso?"
>
> Hoje na plataforma online do LACNIC já é possível adicionar "remarks:" nos
> objetos inetnum e inet6num.
> E isso é excelente! Já permite que cada um resolva seu próprio problema...
> Obs: Se pudessem adicionar o atributo "geofeed:" que é específico para
> esse fim seria lindo.
>
> Também existe no LACNIC o recurso de Geofeeds, onde através do portal do
> LACNIC se pode incluir os blocos dos quais se tem autoritividade(ou
> sub-redes desses blocos) e as referências de geolocalização desses IPs. E
> isso é automaticamente adicionado ao arquivo que pode ser baixado no link:
> https://milacnic.lacnic.net/lacnic/geofeeds
> E isso também é excelente!
>
> Mas... (sempre existe um "mas")
> Existe um pequenino gap entre as duas coisas, onde os blocos que tem algum
> registro de geofeeds não recebem automaticamente o atributo de Geofeed URL.
> Logo, apesar de a informação de Geofeed estar disponível no arquivo CSV,
> ela não pode ser considerada AUTORITATIVA.
> Obs.: Se quiserem validar essa hipótese, sugiro que usem o site
> https://geolocatemuch.com/
>
>
>
> E é agora que as peças de lego se encaixam (pelo menos na minha cabeça) e
> talvez consigamos encontrar uma solução para a questão do Registro.BR não
> ser compliance com RFC9092.
> - E se o registro.br usasse o mesmo modelo ferramenta de cadastro de
> geolocalização por bloco que o LACNIC, com arquivo geofeed.csv hospedado
> por eles mesmos?
>
> Pra mim, essa é uma hipótese que parece razoável.
> Mas gostaria de ouvir outras sugestões dos colegas e principalmente
> gostaria de saber da equipe do Registro.br se eles já têm algo em roadmap
> para isso, ou alguma outra colocação a respeito desse tema.
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>


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