[GTER] Communities no IX.br

Fri Nov 11 17:03:45 -02 2016

Caros,

Seguem algumas sugestões e considerações referentes ao documento sobre o
uso de communities no IX.br. 

Seção "1. Objetivos":

Eu proponho para consideração da equipe do IX.br o seguinte objetivo
extra:

7.  sugerir padrões de configuração, para os participantes do ATM do
IX.br, para a implementação de funcionalidades baseadas em communities.

Seção 2.1, path hiding:

Como sugestão, talvez fosse interessante alterar o último parágrafo para
deixar mais claro como o esquema "multiplas RIBs" funciona, e que o
"aumento de 50% nos prefixos anunciados" não é geral, e sim para quem,
por filtar ou ser filtrado, está sendo vítima de path-hiding ?

Segue uma sugestão de explicação simplificada (baseada em uma que já
enviei nesta thread):

*Antes das alterações propostas neste documento:*

O route-server do IX.br filtra, por participante, o *resultado* da
convergência BGP (escolha da melhor rota) em uma RIB global que é a
mesma para todos (e contém apenas a "melhor" rota na visão *global* do
route-server).  Ele só tem duas escolhas para cada prefixo na RIB
global: ou propaga a melhor rota, ou não propaga nada.

Quando um participante não puder, devido a filtros, receber a "melhor
rota" do ponto de vista da RIB global do route-server, ele não recebe
rota alguma.  Trata-se do "path hiding".

*Depois das alterações propostas neste documento:*

O route-server do IX.br cria uma RIB específica para cada participante,
e aplica os filtros relevantes para aquele participante *antes* de
convergir o BGP (escolher a melhor rota) na RIB específica participante.
 A escolha da melhor rota para cada prefixo só levou em considerações as
rotas que poderiam ser anunciadas (propagadas) para aquele participante.

Portanto, o participante tem muito maior chance de receber alguma rota
para cada prefixo, e o "path hiding" é minimizado ou evitado.

Seção 3, communities:

Acredito que muitos não conheçam a fundo como as extended communities
funcionam.  Mesmo quem as usa em MPLS VPN muitas vezes não tem
conhecimento dos detalhes.

Seria muito interessante descrever brevemente as extended communities
relevantes para o IX.br, que suponho que serão subtipos específicos das
"2-octet AS specific BGP extended communitiy" descrita no RFC 4360 ("BGP
extended communities attribute"), e suas versões para ASN de 32-bits,
descrita pelo RFC 5668 ("4-octet AS specific BGP extended community").

Em particular, "extended communities" não funcionam da mesma forma que
as communities tradicionais (RFC 1997). Quem funcionaria de forma
similar às communities tradicionais seriam as "large communities", que
ainda estão em estado de "draft" na IETF [1].

[1] https://tools.ietf.org/html/draft-ietf-idr-large-community-06

Seção 4, detalhes das communities:

Gostaria de propor para consideração que o IX.br utilize *apenas* as
2-octet e 4-octet AS specific extended communities, não utilizando as
BGP communities básicas (RFC 1997).

Desta forma, tanto as configurações quanto os requerimentos de
funcionalidade de roteador seriam homogêneos para os AS que possuam um
ASN de 16-bits (como o do IX.br) e os que possuam ASN de 32-bits (como
os de boa parte dos participantes).

Há algum valor nesta homogeneidade: nem todo roteador/versão de firmware
tem suporte decente à extended communities.  Se não houver exigência de
patamar mínimo para que os membros do IX.br possam fazer uso destas
novas funcionalidades, corre-se o risco de estender no tempo a
dificuldade operacional dos ASNs de 32-bits.

Esta provavelmente será uma proposta controversa, mas alguém tinha que
colocar na mesa para ser discutida.

Cabe lembrar aos membros do IX.br que a necessidade *técnica* de suporte
a 2-octet e 4-octet AS specific extended communities é definida pela
existência de membros com ASN de 32-bits, ou seja, é um fato consumado. 
Evitar isso implica em publicar o "mapa da gambiarra" (uso de ASN de
16-bits privado para simbolizar cada membro que tem um ASN de 32-bits) e
desistir da transparência à communities por parte do route-server para
(quase) todo o espaço de ASN privado 16-bits.  Não acredito que a equipe
do IX.br aceitaria esta alternativa (e com razão!).

Ou seja, as alternativas são: (a) "obriga o suporte à extended
community", ou (b) "vai ter membro que não consegue ativar um filtro
direcionado a um ASN de 32-bit nem processar a identificação de origem
adicionada pelo IX.br quando a origem possuir ASN de 32-bits".

Seção 4, política 1 e 2:

Sugiro já definir exatamente o formato da extended community
(transitividade, tipo+subtipo).  Como serão removidas pelo route-server,
faz sentido definir que sejam não-transitivas.

Seção 4, política 3:

É uma pena que o RFC 4384/BCP 114 "BGP Communities for Data Collection"
não tenha previsto IXPs.  Não seria o caso de escrever uma extensão do
mesmo, alterando um dos valores reservados de <R> [BCP 114, p.6] para
significar que a origem da rota é um IXP,  usar o campo <AS> para
identificar qual IXP, e definir que para este <R>, o campo <CC> [BCP
114, p.6] conteria informação com sentido determinado pelo IXP (no caso
do IX.br, o código de cidade/área) ?

Assim, o namespace 26162:<algo> fica livre para alguma outra utilização.

Suponho que serão utilizadas 2-octet AS-specific extended communities do
tipo RO (route origin) para identificar o ASN que originou a rota para o
route-server?   Ou será utilizado algum outro subtipo para evitar
confusão com o uso de RO para MPLS VPNs?

Sendo o caso, sugiro já definir exatamente o formato da extended
community (transitividade, tipo+subtipo, etc).

Seção 4, política 4:

Sugiro criar uma seção do documento dedicada à community de RTBH
(blackhole), descrevendo as boas práticas que são sugeridas para
implementação por parte dos *participantes* do IX.br, etc.

Penso que o documento poderia deixar explicito que os route-servers
podem não ser transparentes a communities dentro do espaço de ASN do
NIC.br e IX.br, inclusive porque, pelas boas práticas, o uso desta parte
do espaço de communities é regido pelo NIC.br/IX.br.

Recomendo reservar uma pequena faixa de ASN privados (65000 a 65010 e
64600 a 64610, por exemplo) para implementação futura de funcionalidade
do IX.br.  Os route-servers não devem ser transparente à nenhum tipo de
community (RFC 1997, extended, large[1], etc) que contenha estes ASNs no
campo de global administrator (para RFC1997, "primeira parte" da
community).

[1] https://tools.ietf.org/html/draft-ietf-idr-large-community-06

Seção 5:

Por segurança operacional, talvez faça sentido considerar um passo de
"ativação" da transparência à communities, controlada diretamente pelo
participante do IX.br ?

Neste caso, aconteceria algo do tipo:

Passo 1: O serviço é disponibilizado pelo IX.br nos route-servers, mas
todas as sessões dos membros estão, inicialmente, configuradas para o
estado "descarte bidirecional de communities pelo route-server", ou
seja, não há alteração de comportamento.

Passo 2: Cada membro revisa sua configuração, e quanto achar que está
devidamente ajustada, ele libera a transparência à communities no
route-server, através do painel de self-service no meu.ix.br.

Novas conexões ao IX.br já seriam provisionadas com a transparência
habilitada e travada (não pode ser desabilitada).

Seção 7:

Acredito que seja útil adicionar as referências:

RFC 5668 - 4-octet AS Specific BGP Extended Community
RFC 5701 - IPv6 Address Specific BGP Extended Community Attribute
RFC 6666 - A Discard Prefix for IPv6
RFC 7999 - BLACKHOLE Community

PS: acredito que será realmente necessário publicar exemplos de como
utilizar e gerar cada um dos tipos de extended community implementadas
pelo IX.br ou de implementação sugerida para os participantes
(blackhole), para as plataformas de roteamento mais utilizadas no IX.br.
 A documentação é, em geral, muito esparsa neste ponto: só se acha
facilmente receitas de bolo para MPLS VPN.

-- 
  Henrique Holschuh