Boas Praticas para Protecao de Roteadores e Switches
Índice
Introdução
Este artigo tem como proposta disseminar conhecimentos e boas práticas para a proteção de equipamentos roteadores e switches ("ativos de rede") das infraestruturas de provedores de acesso de Internet, em especial citando as situações e os mecanismos de mitigação correspondentes recomendados tanto pela indústria quanto pelos principais fabricantes para a proteção das infraestruturas de redes do provedor.
Espero que você curta a leitura deste artigo e que seu conteúdo seja bastante útil para o seu projeto de infraestrutura Ethernet/IP. Ah! Não se esqueça: participe das listas de discussão do Brasil Peering Forum!
Uma breve dissertação sobre a segurança da informação
Antes mesmo de falarmos de boas práticas, é necessário frisar que a segurança da informação é uma área absurdamente ampla e que permeia diversos componentes tecnológicos e processuais que se fazem presentes nas organizações nos dias atuais. "A força de uma corrente é tão boa quanto a de seu elo mais fraco" - esta é uma daquelas frases que fazem um sentido absurdo nas vidas dos profissionais que trabalham com Tecnologia da Informação e Comunicação. Simplesmente não há uma única ferramenta ou um pequeno conjunto de procedimentos ou ações que promoverá boa segurança geral; isto é impraticável! Um firewall de 1 milhão de reais na sua rede não te trará - sozinho - a devida segurança, assim como o blackholing de tráfego DoS por mecanismos específicos ou a mitigação de DDoS em sua própria infraestrutura ou realizando isto via um parceiro externo, embora fundamentais para a realidade dos provedores para incidentes de segurança da categoria "(in)disponibilidade", sem dúvidas, enfim, estas estratégias apenas atendem a algumas das diversas possibilidades de ocorrências de incidentes de segurança. Um único procedimento ou o emprego de alguns procedimentos apenas, por mais sofisticados que sejam, muito provavelmente não serão capazes de proteger o seu negócio contra uma magnitude de possibilidades envolvendo incidentes de segurança. E é bom você e o seu provedor ficarem atentos quanto a isto.
A segurança da informação, devido a sua natureza absurdamente ampla, profunda e complexa, precisa ser estudada minuciosamente e considerada adequadamente para toda a organização e seus componentes, os quais, por sua vez, incluem computadores, sistemas operacionais, os recursos e serviços disponíveis nestes sistemas, bancos de dados, infraestruturas de redes (se abríssemos um paralelo aqui, a gama de componentes, apenas na questão "redes", por si só, já seria um tema para uma dissertação de tamanho descomunal!), além do próprio ser humano, que é o principal e primeiro elemento da cadeia de riscos e de situações relacionadas aos incidentes de segurança. Dentre dezenas de outras áreas funcionais, sistêmicas, operacionais e processuais.
Se desenvolvêssemos conceitos sobre as quatro áreas primárias da segurança (Confidencialidade, Integridade, Autenticidade, e Disponibilidade), descobriríamos que, através de ações de assessment de segurança usando múltiplos procedimentos, frameworks e ferramentas, tais como uma análise qualitativa de riscos, dentre muitos outros, todo o nosso aparato tecnológico parece-se mais como um queijo suíço: repleto de "brechas", vulnerabilidades, e com alta probabilidade de ocorrência de problemas, e, em muitos casos, com alto impacto em termos de consequências. Toda empresa - pouco importa o seu tamanho ou porte - precisa analisar corretamente estas questões envolvendo as propriedades da segurança e os estados da informação: processamento, armazenamento, transmissão, e, ultimamente, os dados ou informações consumidas ou utilizadas, e por quais indivíduos, usando quais ferramentas e por quais métodos. As empresas precisam observar as medidas de segurança estudadas e em alinhamento com instrumentos e processos adequados. Dos instrumentos e processos, os quais ditam os rumos da governança da informação nestas empresas, temos, por exemplo, as políticas de segurança, os procedimentos, as tecnologias e ferramentas construídas e arranjadas em regime de compatibilidade e aderência do projeto técnico, das políticas supracitadas, e da governança da segurança como um todo, além dos múltiplos esforços de educação e treinamento de clientes, usuários, funcionários, colaboradores, terceirizados, etc., para fins de prevenção.
Entenda que este artigo não é um curso sobre segurança da informação (e nem me atreveria a fazer isto aqui!) e ao mesmo tempo não oferece um conjunto completo de recomendações que prevê todas as possibilidades e situações. Ao invés disto, este artigo disseminará conhecimentos e boas práticas que são bastante viáveis no ponto de vista de adoção ou implementação, e considerando uma diversidade interessante de situações que são um tanto específicas para a realidade dos provedores de Internet do Brasil. Ao adotar as práticas aqui recomendadas, o seu provedor experimentará um aumento substancial da segurança dos componentes participantes e afetados pelas proposições deste artigo. E, consequentemente, o seu provedor experimentará uma redução drástica de riscos e das probabilidades de sofrer incidentes de segurança sobre estas áreas funcionais aqui disseminadas.
Áreas de interesse deste artigo
Conforme citado anteriormente, este artigo não abordará todas as situações, mas promoverá boa dissertação sobre situações de risco e seus mecanismos de mitigação correspondentes. Estas situações e mecanismos estão categorizados conforme ilustrado a seguir:
Conhecendo os tipos de tráfego, áreas sistêmicas e modelos de processamento e encaminhamento de pacotes
Entendo que este artigo ficará bem melhor se, antes de ir ao ponto e citar os cenários e ferramentas, eu buscar esclarecer alguns fundamentos sobre as arquiteturas de roteadores. Apresentarei aqui conceitos de funcionamento de roteadores em uma rede. Comecemos com uma melhor compreensão sobre os tipos de pacotes que percorrem uma infraestrutura.
OBS: caso o seu entendimento seja bem básico sobre como funciona o roteamento IP e as funções gerais de roteadores e switches, recomendo a leitura do seguinte artigo: Fundamentos de Roteamento para Provedores.
Esclarecendo os tipos de tráfego na perspectiva de roteadores
Pacotes do Plano de Dados
Representa todo o tráfego que que é gerado pelos usuários e que devem ser roteados pelo seu equipamento. Na perspectiva do roteador, o endereço IP de destino é para um serviço de trânsito, ou seja, o pacote não tem como destino final o próprio roteador. É o que melhor define o principal trabalho realizado por roteadores na rede, e não há muito o que citar aqui além do óbvio.
Pacotes do Plano de Controle (Control Plane)
Representa todo o tráfego que é produzido pelos próprios roteadores, particularmente, neste caso específico e exemplificado aqui, os pacotes oriundos dos processos de software correspondente aos protocolos de roteamento. Por exemplo, em uma rede onde o protocolo de roteamento interior for o OSPF, o qual por sua vez é transportado pelo próprio protocolo IP (número do protocolo é o 89), diversos tipos de mensagens são trocadas entre os roteadores OSPF através de suas adjacências ou vizinhanças. Por exemplo, pacotes Hello (Type 1), DBD (Type 2), Link-State Request (Type 3), Link-State Update (Type 4), Link-State Acknowledgement (Type 5). Ou seja, são pacotes produzidos por um processo OSPF de um roteador e que tem como destino o processo de software OSPF de outros roteadores, especificamente as adjacências diretamente conectadas. Outro exemplo clássico, o protocolo BGP-4, o qual é transportado pelo protocolo TCP na porta 179. O BGP-4 emprega pacotes tais como o Open (Type 1), Update (Type 2), Notification (Type 3), Keepalive (Type 4), Route Refresh (Type 5). Ou seja, os pacotes produzidos pelo processo BGP de um roteador são destinados a outros roteadores rodando o BGP-4, seja uma vizinhança interna (iBGP) ou externa (eBGP), diretamente conectados ou por multihop nestes dois tipos de vizinhanças.
Os pacotes produzidos pelos protocolos de roteamento em um roteador tem sempre como destino ou interesse outros roteadores rodando aquele mesmo protocolo de roteamento. O tráfego é classificado aqui como tráfego do plano de controle.
Há outros exemplos de pacotes do plano de controle, mas pretendo não estender-me muito além do necessário para concluir o artigo. Todavia, estes exemplos incluiriam o ARP e NDP (IPv6) para fins de descoberta de vizinhos, resolução de endereços IPv4 e IPv6 para endereços físicos, e como mecanismo de pré-computação de adjacências para posterior programação das estruturas de encaminhamento de pacotes do plano de dados dos roteadores. Outros exemplo de protocolos do plano de controle incluem mecanismos ou protocolos auxiliares para maximizar a disponibilidade da rede com o devido acionamento de uma convergência mais rápida dos IGP ou do BGP, o que seria o caso de um protocolo/serviço tal como o Bidirectional Forwarding Detection (BFD). Ou um protocolo para prover uma segurança adicional contra falhas de comunicação bidirecional em nível mais "físico", o que seria o caso do protocolo Unidirectional Link Detection (UDLD). Ou um protocolo para aumentar a disponibilidade da função de default gateway de usuários de uma VLAN (ex: HSRP, VRRP, GLBP). Até mesmo no caso do MPLS, temos protocolos tais como o Label Distribution Protocol (LDP) e o Resource Reservation Protocol for Traffic Engineering (RSVP-TE). Os pacotes BPDU do Spanning Tree Protocol (STP) são outros exemplos clássicos de tráfego do plano de controle.
Todos os exemplos citados acima são clássicos de pacotes do plano de controle. As duas ilustrações a seguir mostram a troca de pacotes entre dois roteadores com o protocolo de roteamento OSPF.
A seguir, uma ilustração demonstrando o funcionamento do protocolo BFD:
Pacotes do Plano de Gerenciamento (Management Plane)
São exemplos deste tipo de tráfego todos os pacotes oriundos de serviços de gerenciamento e que tenham como o destino o próprio roteador. Obviamente não são classificados com tráfego de gerenciamento na perspectiva de um determinado roteador se o endereço IP de destino destes pacotes não for, obviamente, o próprio roteador. Nestes casos, seria um pacote de trânsito comum
Há uma gama muito grande de protocolos e serviços que são comunicados entre administradores de rede e os roteadores para diversas funções necessárias nas questões de gerenciamento de configurações, falhas, diagnósticos, monitoramento, etc. Exemplos aqui incluem os protocolos Telnet, SSH, SNMP, TFTP e FTP (para transferir software e configurações), NTP, NetFlow, OAM (CFM, E-OAM, MPLS OAM) e tantos outros. Protocolos tais como o Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP) são outros dois exemplos de protocolos de gerenciamento, embora apresentem funções interessantes que viabilizam outras tecnologias necessárias para certos projetos (ex: divulgação da VLAN de Voz (voice vlan) para endpoints).
Assim como os pacotes de tráfego do tipo "plano de controle", os pacotes do plano de gerenciamento tem como destino processos de software em execução no próprio roteador. No entanto, o tráfego de gerenciamento para o roteador (e não o tráfego de gerenciamento de trânsito, onde o destino não é o próprio roteador) não tem relação com a manutenção das estruturas de comutação e de encaminhamento de pacote, exceto, claro, quando tratando-se de ações administrativas envolvendo a configuração de rotas e similares.
Pacotes do Plano de Serviços (Service Plane)
São pacotes gerados por serviços que podem operar exclusivamente por software ou contar com o auxílio de componentes de hardware especializado (CPU dedicada, ASIC, SDRAM...) para as suas funções e processamento, visando melhor desempenho e escalabilidade. Exemplos clássicos aqui temos tráfego de encapsulamento GRE e outras técnicas de tunelamento, além de tráfego IPsec e SSL, dentre outros exemplos. O MPLS L2VPN, apesar de estar mais próximo e alinhado com o tráfego de plano de controle (troca de prefixos e sinalização de labels a serem utilizados) não deixa de ter um "pé" nesta categoria de tráfego.
Outros protocolos e serviços bem conhecidos que podem ser representados ou categorizados como tráfego do plano de serviços incluem o PPPoE e o L2TP, além de outros. O PPPoE, solução bastante tradicional e utilizada pela maioria dos provedores de acesso de Internet do Brasil, é um exemplo bastante clássico e está demonstrado a seguir:
Esclarecendo como o processamento de pacotes de cada tipo de tráfego é realizado pelos roteadores
A partir do momento que você passou a compreender os tipos de tráfego, ficará mais fácil explicar o trabalho que os roteadores realizam sobre os tipos de pacotes na questão "processamento".
É importantíssimo deixar bem claro que há muitas diferenças na forma em que os diversos modelos de equipamentos roteadores, de diversos fabricantes, realizam as funções que serão descritas a seguir. Mesmo quando lidando com equipamentos de um mesmo fabricante há muitas diferenças nas formas em que os pacotes são processados, sejam estes pacotes de trânsito, ou com interesse ao plano de controle ou ao plano de gerenciamento. No entanto, é possível "generalizar", pois estas funções de processamento existem em praticamente qualquer equipamento roteador.
Uma breve explicação sobre os planos de controle e de dados
Para que eu consiga elaborar melhor as explicações sobre o processamento de pacotes, receio ser necessário antecipar algumas informações complementares para agregar mais valor ao tema e esclarecer outras coisas. Para você compreender isto melhor, enquanto o plano de controle hospeda os processos de software referentes aos protocolos de roteamento, juntamente com suas respectivas tabelas e estruturas de dados (ex: OSPF tem a tabela de vizinhos e o LSDB. O BGP tem a tabela de vizinhos e a tabela (de rotas) BGP. O LDP mantém a tabela de labels (LIB). Etc.), além de outras estruturas de dados tais como a tabela ARP (o ARP cache) e a própria tabela de roteamento (RIB), além de muitas coisas que suprimirei por aqui, o plano de dados, por sua vez, possui informações mais "enxutas", específicas e otimizadas para as funções de encaminhamento de pacotes. A principal estrutura de dados mantida no plano de dados é a Forwarding Information Base (FIB) que aponta adjacências e interface de saída, juntamente com outras instruções necessárias para a reescrita de cabeçalhos L2 (ex: tag de VLAN, MTU, endereços MAC de origem e destino). E é justamente e geralmente na FIB onde ocorre o "roteamento" do pacote. Mas isto depende muito da plataforma, do vendor, e das tecnologias empregadas na concepção de arquitetura daquele equipamento, pois há várias técnicas de processamento de pacotes, por exemplo:
- Process Switching: todo o processamento de pacotes é realizado por interrupções de software
- Route Caching: o processamento do pacote sendo feito por software, mas com o reaproveitamento das instruções referentes à reescrita de cabeçalhos mantidas em memória, visando desonerar o processamento da CPU.
- Silicon Switching e Optimum Switching: primeiros esforços da indústria em tratar os pacotes em uma camada mais especializada. Proprietário ("vendor specific"), legado e não mais utilizado.
- Topology-based Switching:
Em outras palavras, em equipamentos de "classe", o processamento de pacotes se dá em hardware especializado e estas plataformas contam com excepcional separação sistêmica entre estes dois principais planos (controle e dados). Se você conseguiu entender ou absorver esta informação, estaremos bem sincronizados então sobre as explicações envolvendo o processamento de pacotes. Ah, a propósito, a ilustração a seguir exemplifica os planos de controle e de dados:
Em algumas plataformas de roteadores, todo o plano de controle é centralizado e fica hospedado em um módulo específico, tal como um módulo de supervisor e controle do tipo "Supervisor", ou "Route Switch Processor" ou "Route Processor". Mas há plataformas onde ocorre uma modularização e distribuição interessantes dos processos de software dos protocolos, onde os protocolos de roteamento ficam neste módulo RSP/RP, mas outros protocolos são "offloaded" para os próprios line cards do equipamento, tais como o ARP, BFD, ICMP das interfaces locais do line card, NetFlow, CFM, CDP, LLDP e outros.
Na maioria das plataformas do mercado o processamento de pacotes também é centralizado e representado por um módulo físico à parte ou componentes integrados. Mas há roteadores no mercado que fazem também a distribuição do plano de dados para os line cards, sendo que cada line card teria neste caso as suas próprias instâncias independentes de FIB e todo o resto necessário para processar o pacote. O encaminhamento de pacotes pode ocorrer em 1, 1,5 ou 2 estágios, mas isto varia muito de acordo com o equipamento em questão.
Como as estruturas de encaminhamento de dados (ex: RIB, mRIB, LIB) são definidas primeiro no plano de controle e, depois, publicadas no plano de dados (ex: FIB+ADJ) depende muito do modelo do roteador. No entanto, posso ilustrar talvez aqui como funcionaria numa plataforma Cisco ASR 9000 à título de curiosidade ou referência:
Processamento de pacotes de trânsito
Retornando à linha de raciocínio original. O processamento de pacotes de trânsito idealmente deve ocorrer na área sistêmica denominada plano de dados ou data plane. Conforme citado anteriormente, o plano de dados hospeda as estruturas de encaminhamento de pacotes com disposição eficiente para a realização de ações de processamento (pipeline) de pacotes, sendo que, em equipamentos de classe "carrier grade", estas estruturas são sempre mantidas em silício especializado.
No entanto, não é porque as funções de encaminhamento de pacotes ocorrem no plano de dados que em 100% dos casos o processamento de pacotes ocorrerá no hardware ou no silício especializado (ex: um ASIC ou FPGA top). Há situações onde os pacotes precisam sofrer tratamento por interrupções de software, e forneço alguns exemplos aqui:
- Pacotes com TTL assinalados com "1", o que provocará a expiração do pacote em trânsito naquele roteador
- Não somente o processamento tem que ser feito em muitos roteadores, não todos, por software aqui, mas, de qualquer forma, o router precisa gerar a mensagem ICMP Type/Code correspondente para sinalizar isto para o remetente do pacote, e isto também é feito por software.
- Pacotes fragmentados
- Pois a fragmentação e remontagem dos pacotes é de fato feita por software.
- Pacotes com opções especiais (ex: IP Router Alert (RFC 6398)), indicando que os roteadores no meio do caminho devam inspecionar detalhadamente o pacote. O Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), e General Internet Signaling Transport (GIST) são exemplos de protocolos/serviços cujos os pacotes utilizam esta marcação no cabeçalho IP.
- Em muitas plataformas mais "low end", o logging habilitado sobre listas de controle de acesso (ACL) obriga todo o processamento do pacote a ocorrer por interrupções de software.
- Pacotes cuja adjacência (next hop e interface de saída) seja desconhecida.
Processamento de pacotes destinados ao próprio roteador
O processamento de pacotes oriundos de protocolos de roteamento tem como destino o próprio roteador, e isto é ainda mais verdadeiro ainda com os protocolos de roteamento interiores. Se o seu roteador receber um pacote do OSPF mas não tiver o OSPF habilitado naquela interface, o equipamento simplesmente descartará o pacote. Agora se a interface estiver habilitada para este protocolo, o pacote é aceito e encaminhado internamente pelo equipamento até ser recebido pela thread destinatária, o qual, por sua vez, validará as instruções e consumirá os dados daquele pacote. Um pacote de BGP, por outro lado, se o endereço de destino não for o próprio roteador o equipamento roteará o pacote normalmente como se fosse um pacote de trânsito, ou seja, diretamente pelo plano de dados e tudo mais. Agora, se o pacote do BGP tiver como destino o próprio roteador, o pacote, ao ser recebido pela interface, tratado pela NPU mapeada àquela interface, fará um "punt" do pacote para que ele percorra internamente o equipamento até a thread correspondente do processo BGP em execução lá no módulo de supervisão e controle (RSP ou RP).
Em algumas plataformas, todo o tráfego "for us", ou seja, destinado ao próprio roteador, é tratado neste módulo RSP ou RP centralizado. Já em outras plataformas (posso citar um exemplo aqui? Plataformas baseadas no Cisco IOS XR (ex: ASR 9000)), alguns pacotes "for us" serão encaminhados (punted) para os processos correspondentes no módulo RSP/RP (o caso do protocolo de roteamento e de gerenciamento) enquanto outros pacotes de protocolos tais como o ARP e o NetFlow, para exemplificar com estes, são processados por software diretamente no próprio line card, ou seja, o plano de controle e (parte) de gerenciamento são distribuídos nestes equipamento. Enfim, sugiro que você estude o (seu) equipamento de seu vendor para conhecer as miudezas de cada caso.
Defenda o seu equipamento: proteção contra ataques de negação de serviço
Considerando todas as explicações fornecidas anteriormente, está na hora de exemplificarmos algumas situações e citarmos algumas ferramentas clássicas para melhorar a segurança de seu próprio roteador.
Mitigação de ataques lançados contra o plano de controle do seu roteador com o policiamento de control plane
A situação:
Indivíduos mal intencionados procuram sabotar a CPU do seu roteador com o envio de múltiplas requisições (inválidas ou não) para os seus protocolos de roteamento. Ou seja, eles inundam o seu processo de roteamento com o envio de muitos pacotes, o que frequentemente resulta em instabilidades no seu plano de controle, indisponibilidade do equipamento e, consequentemente, da rede.
Alguns engenheiros de rede configuram ACLs específicas para a classificação do tráfego e as aplica nas interfaces de conexão externa para tentar mitigar este risco. Nada contra o emprego de ACLs e similares nestas interfaces, inclusive isto pode e deve ser feito para proteger a rede contra determinados tipos de tráfego para certos destinos. No entanto, este procedimento é pouco útil para a proteção do plano de controle, pois não conseguimos policiar os volumes de pacotes e dados chegando até os processos de software referentes aos protocolos de roteamento. É nesta hora que pensamos em uma solução ou ferramenta mais específica: o Policer de Plano de Controle.
O nome pode variar conforme o fabricante, mas o "Control Plane Policer" ou "Control Plane Policing" (CoPP e também o dCoPP) são ferramentas mais adequadas para a mitigação do risco indicado aqui nesta seção do artigo. Como exatamente o CoPP interage e funciona no seu equipamento, isto variará bastante conforme cada modelo ou tipo de roteador. Tentarei generalizar aqui ou talvez fornecer casos com plataformas específicas e bem conhecidas.
O CoPP é um recurso que permite o administrador da rede a gerenciar como os fluxos de tráfego serão tratados pelos processos de software do plano de controle, basicamente prevenindo que o alto volume de tráfego indesejado não vá saturar a CPU (do módulo RSP ou RP, por exemplo), o que afetaria a estabilidade da rede. A exaustão de recursos de uma Route Processor poderá trazer efeitos bastante indesejáveis tanto para a performance e disponibilidade do próprio equipamento quanto da rede como um todo. Não somente pacotes de protocolos de roteamento podem ser lançados em alto volume contra o control plane do seu equipamento: o mesmo poder ocorrer com pacotes destinado a serviços de gerenciamento e por uma variedade grande de protocolos e serviços, tais como SNMP, HTTP, SSH, Telnet, NTP, e outros. Ou seja, o CoPP acaba sendo bem útil para os tipos de tráfego "for us" de controle (protocolos de roteamento), gerenciamento (SSH, SNMP, etc.) e serviços (CDP, LLDP, GRE, IPsec e outros).
Como o CoPP funciona:
O CoPP faz a proteção do Route Processor do roteador através do tratamento dos recursos de processamento como entidade separada com a sua própria interface de entrada ("ingress interface"), vinculada justamente na "porta de entrada" do plano de controle. Ao invés de vincularmos uma ACL numa interface física, vincularemos uma policy mesmo numa interface lógica denominada control-plane, que policia todos os fluxos de tráfego que tem como destino apenas o módulo RP. Desta forma, o roteador não precisa ficar investigando todos os pacotes em trânsito, mas apenas aqueles que tem como destino um processo hospedado no módulo RP (ou seja, adjacências "punted" para o tráfego com interesse local).
Em termos de configuração, o CoPP é configurado de forma muito similar à uma política de QoS com a ferramenta de policiamento de taxa (police ou policing). Neste caso, configura-se as classes de tráfego, envolve as ACLs de classificação indicando os endereços IP de origem, organiza a policy autorizando volumes mais confortáveis vindos de endereços IP de origem confiáveis enquanto, ao mesmo tempo, punindo o tráfego de origem ilícita, o qual será descartado sumariamente no hardware e sem envolver qualquer interrupção de software para estes descartes. Exemplos de classes de tráfego de um CoPP típico:
- Routing: deverão pertencer a esta classe de tráfego pacotes oriundos de protocolos de roteamento, especialmente os de origem autorizada/confiável.
- Management: deverão pertencer a esta classe de tráfego pacotes destinados a serviços de gerenciamento habilitados no roteador, especialmente os de origem autorizada/confiável.
- Normal: aqui seriam classificados o tráfego geral esperado, exceto roteamento e gerenciamento, tais como mensagens ICMP Time-Exceeded, Echo-Request, Echo-Reply, Packet-too-big, Port-unreachable e outros, além de pacotes de GRE e outros.
- Undesirable: deverão ser classificados aqui todos os pacotes de tráfego claramente malicioso, tais como certos TCP RSTs, pacotes fragmentados (isto é, após você redefinir e revalidar o MTU na sua rede, pois você realmente não quer pacotes fragmentados no seu control plane...), e outros tipos de tráfego malicioso.
- Catch-All-IP: todo o resto que não tiver sido identificado nas classes anteriores será identificado aqui.
O CoPP ilustrado:
Quando tratando-se de pacotes IPv4/IPv6, na perspectiva do tráfego em uma rede, podemos categorizar estas transmissões sobre as seguintes partes interessadas:
