[GTER] Tuneis ICMP

[Henrique de Moraes Holschuh]

On 16-07-2012 17:35, Lucas Willian Bocchi wrote:
> Em 16 de julho de 2012 17:06, Henrique de Moraes Holschuh
> <henrique.holschuh at ima.sp.gov.br>  escreveu:
>> On 16-07-2012 10:20, Lucas Willian Bocchi wrote:
>>>
>>> Nos meus roteadores linux, criei um wrapper com libcap e C pra
>>> encher o payload de pacotes com 0. Vamos ver se funciona.
>>
>>
>> Mexer no payload de certos ICMPs vai fazer com que alguns OS os
>> ignore.
> Certamente, mas já havia previsto isso. Tentei fazer um controle
> para que os pacotes válidos de alguns SO's passem pelo wrapper
> livres. Só quando detecto um excesso de pacotes icmp de uma
> determinada direção para a outra que o software começa atuar. Até
> agora está bem, veremos se haverá reclamações.

Essa parte você não havia descrito.

>> Não é mágica que faz o OS conseguir relacionar um ICMP recebido com
>> uma sessão TCP ou UDP ativa: é o payload do ICMP que permite isso.
> Justamente por este motivo que deixo passar as mensagens de controle
> ICMP fora dos controles de banda. Quando um ICMP por acaso cai num
> taildrop da vida há a retransmissão, e às vezes é um PORT
> UNREACHABLE que chega ou alguma outra mensagem que vá fazer com que o
> sistema pare de transmitir / receber naquela porta ou envie um FIN
> para a outra ponta.

Isto é resolvido com priorização e algum AQM que preste.  Tail-drop é
praticamente a pior disciplina de controle de fila que existe...
principalmente com fila longa.

Se quiser tentar resolver o "drop do pacote errado" de verdade e o
bufferbloat causado pelas filas longas (resolver isso resulta num enorme
ganho de usabilidade percebido por qualquer usuário de enlace que
costuma lotar), tente usar a disciplina codel_fq para controlar as
bandas de prioridade de tráfego bulk.

O ruim é que codel_fq só está disponível no OpenWRT de desenvolvimento,
no Linux kernel 3.5, ou em algum backport (deve ser possível fazer um
backport para Linux kernel 3.2.  Para mais antigo, não faço ideia).
Para outros sistemas operacionais, não sei se alguém se habilitou a
escrever ainda (o algorítimo é novo, tem uns poucos meses de
existência... um dos inventores dele é o Van Jacobson).

>> Em outras palavras, sugiro que pare de se esforçar para quebrar a
>> Internet e simplesmente deixe de considerar ICMP como exceção no
>> controle da banda como outros já lhe sugeriram.
>>
> Não considero isso como uma quebra da internet, afinal, já fazemos

Se você zerar o payload de tudo quanto é ICMP, quebra sim.  Quebra o
PMTUD na melhor das hipóteses, bem como os "destination unreachable".

> controle de banda. Isso não é quebrar o princípio da neutralidade de
> rede? As operadoras não zeram pacotes TOS setados na rede da gente e

Controle de banda agregado em si não costuma ser considerado violação de
neutralidade.  Priorizar serviços de forma agregada por tipo (bulk,
latência máxima (RTP, DNS), emergência) também não é costumeiramente
considerado violação de neutralidade.  Já priorizar/despriorizar serviço
de determinado fornecedor (Google/netflix/etc) em relação a outros, é.
Limitar uso agregado dos enlaces de trânsito e peering por tipo de
serviço (ex: p2p) é área cinza, e por usuário é costumeiramente
considerado violação da neutralidade.

Zerar, ou remarcar (alterar) o TOS/DSCP na borda do AS é *normal* e
*esperado*, estando esse detalhe inclusive listado nos RFCs.  As
marcações de QuS e significado das mesmas muda de um domínio
administrativo para outro.  QoS e marcação de tráfego tem que ser
acertado por acordo entre as partes, e é sim considerado ou serviço de
valor adicionado, ou um diferencial de maior qualidade pelo mercado.

Considero que o ideal seria que o cliente (inclusive usuário final) via
de regra possuísse o direito de ter dois ou três prioridades de tráfego
além do BE (best-effort), todas elas limitadas ao máximo de x% da
largura de banda de rede contratada (o resto é ocupado pelo BE).

>> Ou, se vai insistir em interferir com os ICMPs, pelo menos use
>> algum método menos esdrúxulo, como por exemplo, rate-limit.
>>
> Não considero um wrapper em C para simplesmente zerar o payload (e
> não de todos os pacotes, me desculpem por não citar isso) algo
> esdrúxulo.

Sinceramente, na minha opinião colocar isso em produção interferindo
cegamente no _conteúdo_ do tráfego de terceiro (mesmo que o terceiro
seja seu cliente) merece a classificação "esdrúxulo" sim.

Até vou considerar que fazer isso de forma seletiva merece sair da
classificação de "esdrúxulo" e passar para o apenas "incomum, e
altamente não recomendado".  Mas você não tinha dito que era seletivo...

> Fiz para aprender a usar libpcap. Bem interessante! Existem muitas
> outras coisas que são feitas por aí que são bem mais ridículas que
> isso.

Nisso, concordo totalmente!

> Considerarei usar rate-limit no mikrotik.

Depois de simplesmente limitar deforma agregada, mas com menor
prioridade de descarte que TCP e UDP, a técnica mais usada é fazer
rate-limit mesmo.  Você pode separar isso em dois ou três grupos (se
isso não usar recurso demais) e deixar passar pequenos bursts.
Raramente o rate-limit vai descartar ICMP importante, que são bem menos
comuns que o "ping" e o "pong" (echo request e echo reply).  O ruim é
que é um rate-limit por usuário, que pode gerar problema de
escalabilidade se for feito nas caixas de agregação.  Mas se você puder
fazer o rate-limit na CPE, escala muito bem.

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.