<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Adicionando a lista GTER...<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">(memória tá fraca)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qua., 12 de fev. de 2020 às 15:08, Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Como validar se o ASN de Origem de rotas de Black Hole é mesmo autorizado a originar aquelas rotas?</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Atualmente estamos fazendo essa validação através de prefix-lists que monto para cada ASN em nosso cone.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Eu alimento essas prefix-lists com base nos arquivos "delegated latest" de cada RIR...<br><br></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default">Isso funciona razoavelmente bem em quase todos os casos.<br>Mas isso gera alguns problemas, pois nem todo Bloco IPv4 ou IPv6 está necessariamente vinculado a um ASN, ou existem casos em que um Owner de Prefixo pode Delegar aquele prefixo para outro ASN por algum motivo (Comum em casos de CDN ou Mitigação).<br></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default"><div style="font-family:courier new,monospace;font-size:small" class="gmail_default">Já peguei um caso de um Bloco /22 em que havia uma ROA RPKI autorizando /22-24 para o ASN de uma outra empresa...<br></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default">Mas meu filtro de BlackHole rejeitou os anuncios /32 porque nas minhas prefix list (geradas por script com base no NRO), não estava prevista a autorização para aquele ASN.</div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default"><br></div></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default">Então pensei em "Quebrar um pouco" o protocolo RPKI.<br></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default">P.S.: O <a class="gmail_plusreply" id="gmail-m_-251488701228684892plusReplyChip-0" href="mailto:job@ntt.net" target="_blank">@Job Snijders</a> já me disse que não deveria fazer isso nessa thread da LACNOG:</div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default"><a href="https://mail.lacnic.net/pipermail/lacnog/2019-May/007057.html" target="_blank">https://mail.lacnic.net/pipermail/lacnog/2019-May/007057.html</a></div><div style="font-family:courier new,monospace;font-size:small" class="gmail_default"><br></div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small">Porém não consigo achar nenhuma outra solução para eu conseguir entregar o serviço de BlackHole a todos os meus clientes e ainda assim ter certeza que não estou aceitando rotas /32 ou /128 que não façam parte de redes que os ASNs estejam autorizados a anunciar.</span></div><div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></span></div><div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small">Então pensei em:</span></div><div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small"> -> SOMENTE PARA PREFIXOS /32(v4) e /128(v6) COM COMMUNITY DE BLACKHOLE, ignorar a máscara na validação de RPKI.<br></span></div><div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></span></div><div><span class="gmail_default" style="font-family:courier new,monospace;font-size:small">Isso me garantiria que aquele /32 ou /128 está contido em uma rede de alguém que realmente tem autorização para anunciá-la.<br></span></div></div><div><div><div><div><div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Ainda não entrei na parte de como fazer isso...<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - O ideal é que o algorítimo de verificação do RPKI do próprio Router entregassem uma resposta específica para:<br>   "4 Inválido, mas tem uma ROA com um rota de máscara menor que contém esse prefixo"<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - Outra possibilidade é olhar para o código do Validador, e ver o que pode ser ajustado por lá para fazer com que haja uma resposta correta.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - E a última(que é a que eu acho que vou fazer) pegar todas as ROAs válidas, e injetar elas numa base privada de IRR, e fazer consulta lá. Assim o tamanho máximo da máscara do prefixo será ignorado.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">   E continuar a gerar prefix-list através de Scripts, mas agora a partir de um IRR modificado.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">-- <br></div><div dir="ltr"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div>