Manual de referência para a implementação de criptografia e QoS

Transcrição

1 Manual de referência para a implementação de criptografia e QoS Índice Introdução Pré-requisitos Requisitos Componentes Utilizados Convenções Protocolos IPSec AH e ESP Utilize túneis GRE com IPSec Classifique pacotes Configuração de exemplo Política de entrada Política de saída Restrições e problemas relacionados QoS e proteção contra ataque de replay NBAR Contabilidade dupla Criptografia de software e Switching rápida/cef Legado de filas de prioridade e pré-classificação de QoS Criptografia de hardware e QoS Informações Relacionadas Introdução Como os VPNs crescem para incluir tráfego de dados, voz e vídeo, os diferentes tipos de tráfego precisam ser manipulados diferentemente na rede. A qualidade de serviço (QoS) e as características de gerenciamento de largura de banda permitem que um VPN opere em alta qualidade de transmissão para aplicações sensíveis ao tempo, tais como voz e vídeo. Cada pacote é etiquetado para identificar a prioridade e a sensibilidade ao tempo de seu payload e o tráfego é classificado e roteado conforme a sua prioridade de entrega. As soluções de VPN Cisco são compatíveis com uma ampla gama de características de QoS. Este documento é projetado servir como uma referência única para os usuários que configuram a criptografia e as características de QoS do do Cisco IOS na mesmo rede ou conjunto de roteador. Você verá configurações básicas para as políticas de QoS de entrada e de saída na presença de túneis do IP Security (IPSec) e de Generic Routing Encapsulation (GRE). Este documento ajuda a compreender as tarefas de configuração. Igualmente fornece a informação em limitações e em problemas conhecidos, para assegurar o desempenho ótimo e a implementação bem sucedida de serviços do IP aprimorado usando roteadores Cisco. Pré-requisitos Requisitos Os leitores deste documento devem estar cientes destes tópicos: Tecnologia IPSec Para mais documento exaustivo no IPsec, refira uma introdução à criptografia do protocolo de segurança IP (IPSEC). Componentes Utilizados Este documento não se restringe a versões de software e hardware específicas. Convenções Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco. Protocolos IPSec

2 Uma discussão detalhada dos protocolos IPSec é além do alcance deste documento. Contudo, uma vista geral é fornecida nesta seção. Veja a seção da informação relacionada deste documento para uns recursos IPSec mais adicionais. O IPsec define um modelo da autenticação e da criptografia da camada de rede. Consiste em uma troca da chave de criptografia para construir uma conexão segura, e a autenticação e os protocolos de codificação que os dois pares negociem e usem então durante todo a vida da conexão criptografada. O Internet Security Association and Key Management Protocol (ISAKMP) negocia a política de criptografia e fornece uma estrutura comum para gerar as chaves compartilhadas por ipsec peer. O resultado das negociações de ISAKMP é uma associação de segurança (SA). Este exemplo de saída do comando show crypto isakmp policy ilustra os parâmetros usados durante a negociação de um SA: P5R0#show crypto isakmp policy Protection suite of priority 100 encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Pre-Shared Key --- Supports pre-shared keys or a public/private --- key mechanism such as RSA. Diffie-Hellman group: lifetime: #1 (768 bit) seconds, no volume limit --- Lifetime can be based on time or on the number of transmitted bytes. Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime: seconds, no volume limit As negociações de ISAKMP conduzem a uma conexão criptografada (e ao SA) através de que os pares negociam parâmetros IPSec adicionais. Isso inclui os protocolos reais usados para proteger os datagramas IP. Especificamente, os dois peeres de encripção negociam os parâmetros nesta tabela. Parâmetro Grupo do protocolo IPSec Opções Authentication Header (AH) Encapsulating Security Payload (ESP) Para a maioria de aplicativos, o AH ou o ESP são suficiente. Modo de túnel Insira um novo cabeçalho IP de encapsulamento enquanto retém e criptografa o cabeçalho IP original. Modo de transporte - Retém o cabeçalho IP original, mas altera o campo do protocolo para um valor de 51 ou 50 para refletir o cabeçalho AH ou ESP, respectivamente. Durante a fase de negociação, o ISAKMP automaticamente "recua" para modo de túnel caso o modo de transporte seja desejado, mas não possa ser estabelecido. Modo Nota: O RFC 2401 usa os termos exteriores ou encapsulando o encabeçamento para descrever o cabeçalho IP novo com modo de túnel e o encabeçamento interno para descrever o cabeçalho de IP original. Texto extraído do RFC: O endereço de origem e o endereço de destino exteriores do cabeçalho IP identificam os valores-limite do túnel (o encapsulator e o decapsulator). Os endereços de origem e de destino do cabeçalho IP interno identificam o remetente e o destinatário originais do datagrama (sob a

3 perspectiva desse túnel), respectivamente. Estes termos são utilizados no restante deste documento. Transform Set AH para a autenticação somente. ESP para a autenticação e a criptografia. A saída do comando show crypto ipsec sa address ilustra IPsec SA, cada qual é identificado por um Security Parameter Index (SPI). Por exemplo, a conexão identificada com um SPI de 0x21A85375 ( ) usa o algoritmo do MD5-HMAC para o AH e o DES para ESP. P5R0#show crypto ipsec sa address dest address: Address of the IPSec peer. protocol: AH spi: 0x93B90183( ) transform: ah-md5-hmac, in use settings ={Tunnel, } slot: 0, conn id: 2808, flow_id: 405, crypto map: testibm sa timing: remaining key lifetime (k/sec): ( /1654) replay detection support: Y spi: 0x21A85375( ) transform: ah-md5-hmac, --- AH uses the MD5-HMAC algorithm. in use settings ={Transport, } slot: 0, conn id: 2812, flow_id: 407, crypto map: testibm sa timing: remaining key lifetime (k/sec): ( /1604) replay detection support: Y protocol: ESP spi: 0xDFF0FEC3( ) transform: esp-des, in use settings ={Tunnel, } slot: 0, conn id: 2810, flow_id: 405, crypto map: testibm sa timing: remaining key lifetime (k/sec): ( /1654) IV size: 8 bytes replay detection support: Y spi: 0xDB00B862( ) transform: esp-des, --- ESP uses DES. in use settings ={Transport, } --- Transport mode accepted for this flow. AH e ESP slot: 0, conn id: 2814, flow_id: 407, crypto map: testibm sa timing: remaining key lifetime (k/sec): ( /1568) IV size: 8 bytes replay detection support: Y Como referido na tabela acima, o AH e o ESP podem ser usados independentemente ou junto. Contudo, porque a maioria de aplicativos somente um é suficiente. Para both of these protocolos, o IPsec não define os algoritmos de segurança específicos para usar-se. Em lugar de, fornece um framework aberto para executar algoritmos padrão do setor. O AH fornece a integridade sólida e a autenticação para datagramas IP usando os algoritmos de hash SHA ou MD5. Igualmente fornece a nãorepudiação. O cabeçalho AH tem pelo 12 bytes e é exemplificado no gráfico abaixo. A IANA (Autoridade responsável pela atribuição de números na Internet) atribuiu o número de protocolo 51 ao AH. Assim, na presença de um cabeçalho AH com os modos de túnel e de transporte, o cabeçalho IP usa o valor 51 no campo protocolo. Este gráfico mostra o formato de um pacote com um IPSec AH. Com modo de túnel, o valor de byte do Tipo de serviço (ToS) é copiado automaticamente do cabeçalho de IP original ao cabeçalho de túnel. Consulte a seção Classificar pacotes neste documento para obter mais informações.

4 O ESP consiste em um cabeçalho não criptografado seguido por dados criptografados e por um reboque cifrado. O ESP fornece a criptografia e a autenticação. Como com AH, o ESP apoia os algoritmos de hash SHA e MD5 para a autenticação. Apoia o DES e o 3DES como protocolos de codificação. O cabeçalho de ESP é pelo menos 8 bytes e é ilustrado neste gráfico. O IANA atribuiu o número de protocolo 50 ao ESP. Assim, na presença (somente) de um cabeçalho de ESP com modo de túnel e modo de transporte, o cabeçalho IP usa um valor dos 50 pés no campo do protocolo. Este gráfico mostra o formato de um pacote com um cabeçalho IPSec ESP e um reboque. Com o modo túnel, o valor de byte ToS é copiado automaticamente a partir do cabeçalho IP original para o túnel do cabeçalho. Consulte a seção Classificar pacotes neste documento para obter mais informações. Utilize túneis GRE com IPSec O IPsec não apoia o Multicast ou o tráfego não-ip, tal como as trocas de pacote Internetwork IPX (IPA) e o APPLETALK. O fato de que o IPsec não apoia o Multicast significa que não pode levar a informação do protocolo de roteamento que é Multicast como EIGRP ( ) e OSPF ( e ). O GRE é usado para encapsular o tráfego multicast. Depois, isto pode ser criptografado pelo IPSec, de maneira que o tráfego de Routing Protocol possa fluir por um VPN. Para uma configuração de exemplo do IPsec e do GRE, refira configurar um túnel GRE sobre o IPsec com OSPF. O encabeçamento do túnel GRE introduz um segundo nível do encapsulamento. Se você não usa somente túneis GRE e nenhum IPsec, refira a Opção Qualidade de Serviço em interfaces do túnel GRE. Esta figura ilustra o pacote encapsulado com cabeçalhos IPSec, GRE e IP original: Classifique pacotes A classificação define o processo de combinar uns ou vários campos na camada 2,3 de um pacote, ou 4 encabeçamentos e então colocação desse pacote em um grupo ou em uma classe de tráfego. Com a ajuda da classificação do pacote, você pode particionar o tráfego de rede em diversos

5 níveis de prioridade ou classes de serviço. Ao configurar o IPSec com GRE, a abordagem de classificação mais simples é combinar os valores de precedência do IP ou do DSCP. O Cisco IOS Software Release 11.3T introduziu o apoio para o IPsec e junto com ele a característica da preservação de byte de ToS. Com esse recurso, o roteador copia automaticamente o valor do cabeçalho de ToS do pacote de IP original para o cabeçalho de encapsulamento de IP quando é usado IPSec em modo de túnel. A versão 5.1 e mais recente do Cisco PIX Firewall e a versão 3.5 e mais recente do VPN 3000 series concentrator apoiam o copi do byte ToS. Seção 5.1.2, construção de cabeçalho para o modo de túnel, no RFC 2401 encarrega de copiar os bit ToS IP. A preservação de bytes de ToS também se aplica a AH. Igualmente note que o ESP no modo de transporte retém o cabeçalho de IP original, e o valor original ToS é transmitido mesmo sem preservação de byte de ToS. Se os pacotes chegam no roteador sem uma Precedência IP do grupo ou valores DSCP, você pode marcar baseado na classe para observar os cabeçalhos de pacote de informação antes da criptografia ou do encapsulamento. Quando os pacotes alcançam a interface de saída, a política emissora de QoS pode então combinar e atuar nos valores observados. Quando se configura uma política de QoS com base em precedência de IP, duas políticas são aplicadas. Entrada Saída Tipo de política Ações de política Local da política Marque a Precedência IP no cabeçalho de IP original. Oferece garantias mínimas de largura de banda às classes de tráfego diferenciadas pela precedência IP. Interface de ingresso Interface de saída Esta tabela mostra uma configuração para uma política de QoS baseada na Precedência IP: Política de entrada QoS TOS-baseado access-list 150 permit tcp any any eq www access-list 150 permit tcp any eq www any access-list 151 permit tcp any any eq telnet access-list 151 permit tcp any eq telnet any class-map match-any ingress-web match access-group 150 class-map match-any ingress-telnet match access-group 151 policy-map settos class ingress-web set ip precedence 1 class ingress-telnet set ip precedence 2 interface ethernet 0/0 service-policy in settos Política de saída class-map match-any egress-web match ip precedence 1 class-map match-any egress-telnet match ip precedence 2 policy-map usetos class egress-web bandwidth percent 25 class egress-telnet bandwidth percent 15 interface serial 1/0 bandwidth 512 service-policy out usetos crypto-map TEST Embora não mostrado, você pode igualmente aplicar o Weighted Random Early Detection (WRED) a cada classe como um mecanismo alternativo de queda à queda traseira. O valor de precedência de IP comentado é transportado pela rede. Sendo assim, certifique-se de implementar políticas consistentes por meio do domínio QoS para evitar classificação e desempenho inesperados.

6 Alternadamente, você pode querer classificar o tráfego baseado em valores diferentes da Precedência IP ou do DSCP. Por exemplo, você pode querer classificar os pacotes baseados no fluxo IP ou mergulhar a informação 3, tal como o endereço IP de origem e de destino. Para fazer isso, você deve usar o recurso QoS para VPNs. Esta característica é permitida com o comando qos pre-classify e está disponível para o Roteadores VPN Cisco série 7100 e os Cisco 7200 Series Router desde o Cisco IOS Software Release 12.1(5)T e para 2600 e 3600 Series Router desde o Cisco IOS Software Release 12.2(2)T. Refira configurar o QoS for Virtual Private Networks. O mecanismo de pré-qualificação qos permite que os Cisco routers façam uma cópia do cabeçalho IP interno e executem uma classificação QoS antes da criptografia, com base nos campos do cabeçalho IP interno. Sem esta característica, o Engine de classificação vê um único fluxo somente cifrado e escavado um túnel desde que todos os pacotes que transversal através do mesmo túnel tenha o mesmo cabeçalho de túnel e receba o mesmo tratamento no caso da congestão. Se sua política de classificação combina com o byte ToS, você não precisa de usar o comando qos pre-classify desde que o valor ToS é copiado ao cabeçalho externo à revelia. Uma política de QoS simples pode ser criada para classificar o tráfego de acordo com as classes baseadas em precedência de IP. Contudo, para diferenciar o tráfego dentro de uma classe e para separá-lo em filas com base no fluxo múltiplas, o comando qos pre-classify é exigido. Nota: A cópia do byte ToS é feita pelo mecanismo de tunelamento e não pelo comando qos pre-classify. É possível aplicar o comando qos pre-classify a vários pontos da configuração, conforme ilustrado aqui. GRE somente - Configurar o comando qos pre-classify na interface de túnel. interface Tunnel0 ip address qos pre-classify tunnel source tunnel destination interface serial 0/0 ip address fair-queue IPsec somente - Configurar o comando qos pre-classify sob o crypto map. crypto map TEST 10 ipsec-isakmp set peer set transform-set SET match address Test qos pre-classify interface serial 0/0 ip address crypto map TEST random-detect random-detect flow IPsec e GRE - Configurar o comando qos pre-classify na interface de túnel e sob o crypto map. crypto map TEST 10 ipsec-isakmp set peer set transform-set SET match address Test qos pre-classify interface Tunnel0 ip address qos pre-classify tunnel source tunnel destination crypto map TEST interface serial 0/0 ip address service-policy out matchportnumbers crypto map TEST Termine estas etapas para configurar a pré-classificação de QoS com IPsec e GRE. 1. Configurar um crypto map e especifique o comando qos pre-classify no modo da configuração de mapa. crypto map cryptomap_gre1 10 ipsec-isakmp set peer set transform-set transf_gre1_transport match address 130 qos pre-classify

7 2. Use o comando show crypto map confirmar sua configuração vpn1#show crypto map Crypto Map: "cryptomap_gre1" idb: Loopback0 local address: Crypto Map "cryptomap_gre1" 10 ipsec-isakmp Description: Crypto map on GRE1 tunnel mode transport >3/30 Peer = Extended IP access list 130 access-list 130 permit gre host host Current peer: Security association lifetime: kilobytes/3600 seconds PFS (Y/N): N Transform sets={ transf_gre1_transport, } QOS pre-classification Defina uma interface do túnel GRE e aplique os comandos crypto map e qos pre-classify. 4. interface Tunnel0 ip address qos pre-classify tunnel source Loopback0 tunnel destination crypto map cryptomap_gre1 Use o comando show interface tunnel 0 confirmar que a pré-classificação de QoS está permitida. 2621vpn1#show interface tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Description: VPN resilience test - 1st GRE tunnel Interface mode transport >3/3 Internet address is /30 Tunnel source (Loopback0), destination Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled, fast tunneling enabled Last input 00:00:04, output 00:00:04, output hang never Last clearing of "show interface" counters 00:00:51 Queueing strategy: fifo (QOS pre-classification) Output queue 0/0, 0 drops; input queue 0/75, 0 drops A saída acima ilustra que a interface de túnel continua a utilizar first in, first out (FIFO), conforme a estratégia de enfileiramento, mesmo com a pré-classificação de QoS e o enfileiramento simulado ativados. Isto é ilustrado no show command output (resultado do comando show) com a linha estratégia de fila: fifo (PRE-classificação QoS). o GRE e os túneis de IPsec exigem o enfileiramento de FIFO desde que um dispositivo de destino deixa cair os pacotes de IPsec que chegam fora de serviço. Em um ambiente VPN, você pode aplicar uma política de serviços de QoS à interface de túnel ou à interface física subjacente. A decisão sobre a necessidade de se configurar o comando qos pre-classify depende de qual cabeçalho e quais valores de cabeçalho serão utilizados para classificação. Se você quer classificar os pacotes baseados no cabeçalho interno, aplique a política à interface de túnel sem o comando qos pre-classify. Se você quer classificar os pacotes baseados no cabeçalho externo, aplique a política à interface física sem o comando qos pre-classify. Se você quer classificar os pacotes baseados no cabeçalho interno e aplicar a política à interface física desde que a interface física pode ser um ponto de congestão, aplique a política a uma interface física e permita o comando qos pre-classify. Em maio 2002, Cisco recomenda o aplicativo de uma política hierárquica à interface física em um ambiente VPN. Refira a política de tráfego como um exemplo da política de QoS (políticas de tráfego hierárquicas). Nesta configuração, a política de parentes inclui uma classe pelo túnel para classificar ou combinar em todo o tráfego que pertence a esse túnel e usa o comando shape limitar a saída do túnel. A classificação dos fluxos dentro do túnel é aplicada com a ajuda de uma política infantil e pode ser baseada no cabeçalho IP interno com o comando qos preclassify ou no cabeçalho IP exterior sem o comando qos pre-classify. Assegure-se de que o valor de largura de banda especificada no comando shape de cada um das políticas de parentes para os túneis não faça oversubscribe a taxa da relação. Estão aqui as etapas a esta configuração. 1. Crie as classes da política infantil. Por exemplo, escolha combinar no DSCP particular ou nos valores de precedência IP se aqueles valores são ajustados já nos fluxos de tráfego. 2. class-map ef match ip dscp ef class-map af match ip dscp af31 Crie o mapa da política infantil. Especifique as classes utilizadas na etapa 1. Aplique ações de QoS nessas classes. Os exemplos de tais ações incluem a especificação das filas de prioridade com o comando priority ou a especificação de uma garantia de largura de banda mínima com o comando bandwidth. policy-map QoS

8 3. class ef priority percent a% class af bandwidth percent b% Crie as classes da política de parentes. Use o comando access-list para especificar ACLs que classificam todo o tráfego de um túnel específico combinando os endereços da fonte do túnel e do IP de destino. Em seguida, crie um mapa de classes e use o comando match access-group para referenciar o ACL. 4. class-map class-tunnel1 match access-group 101 class-map class-tunnel2 match access-group 102 class-map class-tunnel3 match access-group 103 Crie o mapa da política de parentes. Especifique as classes que você usou em etapa 3. aplica o comando shape a cada classe limitar a saída de todo o tráfego que vem da interface de túnel. 5. policy-map main class class-tunnel1 shape average x1 bps service-policy QoS class class-tunnel2 shape average x2 bps service-policy QoS class class-tunnel3 shape average x3 bps service-policy QoS class class-default shape average x4 bps Aplique o mapa da política de parentes à interface física com a ajuda do comando service-policy. interface serial 1/0 service-policy out main Nota: Se seu aplicativo exige a pré-classificação de QoS em um IPsec ou o IPsec com ambiente de GRE, permita o comando qos pre-classify no crypto map. Os critérios de correspondência da classe principal devem ser o mesmo grupo de acesso que é utilizado pelo mapa de criptografia. No exemplo, os critérios de verificação de repetição de dados para class-tunnel1 usam o mesmo grupo de acesso que o crypto map, que você anexa à interface física ou à interface do túnel GRE. Cisco apoia a criptografia com base no software e a criptografia baseada em hardware, igualmente conhecidas como aceleradores de criptografia. Esta tabela lista os aceleradores de hardware de criptografia da Cisco e o suporte para pré-classificação: Plataforma Cisco 1700 Series Hardware de criptografia VPN de velocidade com fio por meio da criptografia de hardware. A série Cisco 2600 suporta um slot AIM (módulo de integração avançado). O Cisco 3660 suporta dois slots AIM. Suporte à Pré- Classificação QoS O Cisco IOS Software Release 12.2T apoia o Low Latency Queuing (LLQ) antes de cripto. Cisco e Series AIM-VPN/BP (desempenho de base) AIM-VPN/EP (desempenho aprimorado) AIM-VPN/MP (desempenho meados de) Desempenho AIM-VPN/High (HP) Disponível, até à data do Cisco IOS Software Release 12.2(2)T. Cisco e Series Cisco e Módulo de rede privada virtual de roteador de multiserviço modular do aplicativo do equipamento da premissa do cliente do Cisco 7200 Series Router primeiro para os pacotes do roteador VPN 2600 e 3600 Cisco do Cisco e Series O SA-VAM é o módulo de aceleração da VPN. Instala em um slot de adaptador de porta no Cisco ou Series e instala no entalhe do módulo de serviço no Cisco 7100 Series. SA-ISA(=) e SA-ISM(=) são o Adaptador O Cisco IOS Software Release 12.2T apoia o LLQ antes da característica cripto. Disponível no Cisco IOS Software Release 12.2,

9 Series de Serviço Integrado e o Módulo de Serviço Integrado, respectivamente. no 12.2T, no 12.1E, e no 12.0(5)XE. O comportamento de mudanças de políticas de QoS na presença da criptografia de hardware quando você alterar o trajeto de switching dos pacotes dentro do roteador. Com criptografia de hardware, o CPU reorienta um pacote ao módulo de criptografia antes que esteja enfileirado na interface externa. Portanto, em um ambiente IPSec com GRE e criptografia de hardware, há dois pontos potenciais de congestionamento: Fila de criptografia Apoios FIFO somente. Quando você usa ou o hardware ou criptografia de software, pacotes sensíveis a retardo, tais como a Voz sobre córregos do Real-Time Transport Protocol (RTP) IP (VoIP), você pode encontrar alguma latência na única fila de FIFO do processo do encapsulamento. Esta latência aumenta enquanto os pacotes sensíveis a retardo chegam quando a fila já guarda uma grande quantidade de tráfego de dados. Para minimizar todo o impacto, selecione um Cisco Router Series com uma aceleração de hardware apropriadamente escalada da arquitetura e do uso. Se a crypto-engine não é congestionada, a seguir não levanta nenhum problema para ter um FIFO para a crypto-engine, a menos que o FIFO for demasiado pequeno absorver a intermitência de tráfego. Se você executa VoIP através da crypto-engine, você pode querer compreender a latência através do motor. Fila de nível de interface Apoia métodos de enfileiramento especiais. À revelia, uma interface de túnel é uma interface lógica com um parâmetro de largura de banda dos kbps 9. Este parâmetro de largura de banda é usado somente por protocolos de camada superior tais como o EIGRP e o OSPF. Não limita realmente a taxa de emissor ou a largura de banda de interface que o tráfego em túnel pode usar. Portanto, talvez você precise implementar a modelagem baseada em classe na interface de túnel para criar filas de congestionamento "artificial" ou filas de modelagem. O modelagem baseada em classe limita a taxa de emissor e condu-la a um estado congestionado na interface de túnel lógico. A interface de túnel começa a enfileirar os pacotes em excesso que são mantidos pelo modelador, e sua política de enfileiramento complexa se aplica aos pacotes em excesso. O enfileiramento de FIFO dos apoios de crypto-engine do hardware somente. Portanto, se você aplicar uma política de serviço com LLQ na interface física de saída pela qual o tráfego de túnel é transmitido, verifique se o desempenho do processamento de IPSec é superior ao da interface de saída. Isso permite que o mecanismo de enfileiramento de prioridade da interface esteja operante e impede que o mecanismo crypto se torne um gargalo FIFO. No Cisco IOS Software Release 12.1, a classificação comum foi introduzida para assegurar-se de que os pacotes combinassem a uma única classe em um mapa de política (refira o ordem de operação de Qualidade de Serviço para mais informação). Em um ambiente VPN, um resultado deste realce é que a classificação de fluxos de tráfego criptografado dentro de um túnel de IPsec falha, mesmo quando uma política de serviços especifica a harmonização na Precedência IP ou os valores DSCP no cabeçalho de túnel. Este problema foi solucionado no Cisco IOS Software Release 12.2(10) nos IDs de bug CSCdw90486 (somente para clientes registrados) e CSCdx08427 (somente para clientes registrados) da Cisco. Nos Cisco IOS Software Release que incluem as mudanças executaram devido a estes introduzem erros de funcionamento, o comportamento de classificação com criptografia de hardware e de software são agora consistentes. Esta tabela descreve o comportamento de características MQC com e sem a pré-classificação de QoS após o reparo. Para as Plataformas que não apoiam pré-classificação nem não têm permitida pré-classificação, o comportamento de MQC no nenhum preclassify a coluna é esperado. Esta tabela utiliza novamente as mesmas definições usadas em todo este documento para cabeçalho interno e externo. Pré-classificar Aceleradores de criptografia de hardware e CEF classificação comum interna externa comandos configure e police interna externa enfileiramento interna externa WFQ baseado em fluxo interna externa Aceleradores de criptografia de hardware e comutação do processo classificação comum interna externa comandos configure e police interno (1) externa enfileiramento interna externa WFQ baseado em fluxo interna externa Criptografia de Software e CEF classificação comum interna externa comandos configure e police interna externa enfileiramento interna externa WFQ baseado em fluxo interna externa Criptografia de software e switching de processo classificação comum interna externa comandos configure e police interno (1) externa enfileiramento interna externa WFQ baseado em fluxo interna externa Nenhum Preclassify

10 Nota: Embora os comandos set and police atuem em uma classe preclassified, a marcação do pacote ocorre somente no cabeçalho externo. Configuração de exemplo Esta configuração de exemplo ilustra os comandos para criar políticas de serviço de QoS para um IPSec com ambiente GRE. Um túnel GRE conecta os ipsec peer, e os pacotes em túnel são cifrados com a ajuda do IPsec. Crie uma política de entrada que aplique o Class-based Marking para ajustar a Precedência IP. Crie uma política emissora que limite cada túnel criptografado a uma largura de banda máxima usando o modelagem baseada em classe e igualmente aplique garantias de largura de banda mínima através do Class-Based Weighted Fair Queuing (CBWFQ). Política de entrada Termine estas etapas para criar uma política de entrada que aplique o Class-based Marking Permita o CEF com o comando ip cef. O CEF é exigido para o Class-based Marking. Refira quando é o CEF exigido para Qualidade de Serviço? para obter mais informações. Defina os critérios em que para classificar o tráfego em classes. Esta configuração define a classe "flow-hi" (fluxo alto) para o tráfego Telnet e a classe "flow-low" (fluxo baixo) para o tráfego ICMP. Defina um mapa de política e defina ações QoS às classes definidas. Aplique sua política à relação. Neste caso, é a subinterface serial. Esta tabela mostra uma configuração para uma política de entrada do Class-based Marking. ip cef Política de entrada do Class-based Marking class-map match-any flow-low match protocol icmp class-map match-any flow-hi match protocol telnet policy-map qos-in class flow-hi set ip precedence 4 class flow-low set ip precedence 2 int s0/0.1 service-policy input qos-in router#show policy-map interface s0/0.1 Serial0/0.1 Service-policy input: qos-in) --- Apply input policy named "qos-in." Class-map: flow-hi (match-any) 447 packets, bytes 30 second offered rate 5000 bps, drop rate 0 bps --- Input rate for class named "flow-hi." Match: protocol telnet 447 packets, bytes 30 second rate 5000 bps --- Input rate for class named "flow-hi." QoS Set ip precedence 4 Packets marked 447

11 --- Number of packets marked. Class-map: flow-low (match-any 237 packets, bytes 30 second offered rate bps, drop rate 0 bps Match: protocol icmp 237 packets, bytes 30 second rate bps QoS Set ip precedence 2 Packets marked 237 Class-map: class-default (match-any) --- The default class is automatically defined. 1 packets, 48 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Política de saída Esta configuração cria uma política de saída hierárquica, também conhecida como política aninhada. Consulte a seção Traffic Policy as a QoS Policy (Hierarchical Traffic Policies) Example [&Exemplo de política de tráfego como uma política de QoS (políticas de tráfego hierárquicas)] para obter mais informações. A política "pai" aplica a modelagem baseada em classe para limitar a taxa de saída total da interface de túnel e a política "filho" aplica garantias mínimas de largura de banda, usando o CBWFQ para o excesso colocado em fila. Estas são as etapas para esta configuração Crie a política infantil. Essa configuração define a classe "ipsec-hi" para o tráfego de Telnet remarcado e a classe "ipsec-low" para o tráfego de ICPM remarcado. Esta configuração usa o mapa de política IPsec-fluxo para aplicar o CBWFQ ao telnet e ao tráfego ICMP usando o comando bandwidth. Crie a política de parentes. Essa configuração define a classe "ipsec" e molda o tráfego correspondente a 16 kbps. Aplique a política infantil dentro da política de parentes. Esta configuração aplica a política infantil "ipsec-flow" como uma ação de QoS dentro da política pai "qos-out". A ação de QoS é CBWFQ para os pacotes retidos e enfileirados pelo shaper. Aplique a política de parentes à relação. Neste caso, é a subinterface serial. Esta tabela mostra uma configuração para que uma política emissora dê forma e aplique ao CBWFQ, com base nos valores observados. class-map match-all ipsec-hi match ip precedence 4 class-map match-all ipsec-low match ip precedence 2 policy-map ipsec-flow class ipsec-hi bandwidth 8 class ipsec-low bandwidth 8 class-map match-all ipsec match protocol gre policy-map qos-out class ipsec shape average service-policy ipsec-flow int fa0/0 service-policy output qos-out Modelagem e Política de Saída de CBWFQ --- Apply the policy to the physical interface through --- which the tunnel traffic is transmitted. router#show policy-map interface fast 0/0

12 FastEthernet0/0 Service-policy output: qos-out --- "Parent" policy named "qos-out." Class-map: ipsec (match-all) 1422 packets, bytes 30 second offered rate bps, drop rate 0 bps --- Egress rate before shaping. Match: protocol gre Traffic Shaping Target Byte Sustain Excess Interval Increment Adapt Rate Limit bits/int bits/int (ms) (bytes) Active Queue Packets Bytes Packets Bytes Shaping Depth Delayed Delayed Active yes Service-policy : ipsec-flow --- "Child" policy named "ipsec-flow." Class-map: ipsec-hi (match-all) 788 packets, bytes 30 second offered rate bps, drop rate 0 bps Match: ip precedence 4 Weighted Fair Queueing Output Queue: Conversation 25 Bandwidth 8 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 389/ (depth/total drops/no-buffer drops) 4/0/0 Class-map: ipsec-low (match-all) 634 packets, bytes 30 second offered rate bps, drop rate 0 bps Match: ip precedence 2 Weighted Fair Queueing Output Queue: Conversation 26 Bandwidth 8 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 270/ (depth/total drops/no-buffer drops) 64/2/0 Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Class-map: class-default (match-any) 115 packets, bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any Nota: A política principal usa o comando match protocol gre command para especificar a combinação no valor do protocolo atribuído ao GRE no cabeçalho IP. Baseado na ordem da execução das características do Cisco IOS, os ACL e as características de QoS veem pacotes não criptografado. Assim, a configuração dos ACL que combinam no valor de protocolo AH ou ESP (51 e 50 pés, respectivamente) não trabalha (Bug da Cisco ID CSCdu63385 (clientes registrados somente) e CSCdv20737 (clientes registrados somente)). Essa restrição aplica-se à criptografia de hardware e software. Em casos raros, QoS apresenta pacote classificado baseados no cabeçalho IP alterado dos pacotes criptografado em um roteador configurado para o CEF switching. A razão é que os pacotes CEF realmente estavam sendo processo comutado quando o código e o CEF criptos errada não poderiam encontrar uma adjacência do CEF válido. Nota: Se você usa o comando match protocol em um mapa da classe combinar em protocolos não-ip, tais como o IPX e o APPLETALK, e igualmente permite qos PRE-classifica para combinar em valores no cabeçalho interno, a classificação baseada no cabeçalho interno não trabalha. Restrições e problemas relacionados Esta seção discute os problemas conhecidos e as ações alternativas relativos ao aplicativo de cripto e de QoS no mesmo roteador. QoS e proteção contra ataque de replay

13 Alguns grupos de transformação criptográfica oferecem proteção contra replay, que funciona quando um número de seqüência é aplicado ao cabeçalho de criptografia. Em uma interface congestionada com o fancy queuing, um pacote de prioridade baixa pode ser atrasado em uma fila e então chegar no roteador que decifra depois que a janela anti-resposta foi excedida. Neste caso, o dispositivo que recebe deixará cair o pacote. Além, se um pacote criptografado chega no destino fora da sequência por um determinado indicador (ajustado atualmente a 64 pacotes), o pacote é deixado cair. Cisco está atualmente na procura de métodos para superar estas limitações. Note que a proteção anti-replay não pode ser desabilitada destes transforma em qual é executada. esp-sha-hmac esp-md5-hmac ah-md5-hmac Ah-sha-hmac Use o comando show crypto ipsec sa determinar se o apoio da anti-repetição está permitido para cada IPsec SA. NBAR 2611-ch5#show crypto ipsec sa interface: Tunnel0 Crypto map tag: Test, local addr inbound esp sas: spi: 0xDE92271( ) transform: esp-des esp-sha-hmac, in use settings ={Transport, } slot: 0, conn id: 2000, flow_id: 1, crypto map: Test sa timing: remaining key lifetime (k/sec): ( /99) IV size: 8 bytes replay detection support: Y O NBAR não é configurável nas interfaces lógica onde a escavação de um túnel ou a criptografia são usadas. Não é apoiado igualmente em nenhuma interface física configurada com um crypto map. Por isso, não é possível usar o NBAR para classificar o tráfego com base em informações de pacote de camada mais elevada, como um URL ou nome de host de servidor de Web, para qualquer política de QoS onde GRE e/ou IPSec estejam sendo usados. Esta restrição resulta do número de bytes do cabeçalho de pacotes que o recurso de pré-classificação salva e faz referência. Especificamente, a pré-classificação de QoS chama um API nos IO antes que um pacote esteja encapsulado. Essa API obtém uma cópia das informações do cabeçalho do pacote original. Quando o pacote bate eventualmente a função de QoS da saída, QoS pode ser aplicado ao pacote baseado em alguma da informação salvar tal como a porta TCP ou o endereço IP de destino real. Contabilidade dupla Os contadores de classificação na saída do comando show policy-map interface podem exibir duas vezes o número de pacotes de túnel conhecidos criptografados em uma configuração com CEF, GRE e IPSec. Este exemplo ilustra essa condição. router#show policy-map interface fa0/0 FastEthernet0/0 Service-policy output: qos-out Class-map: ipsec (match-all) 44 packets, 8580 bytes 30 second offered rate 1000 bps, drop rate 0 bps Match: protocol gre Traffic Shaping Target Byte Sustain Excess Interval Increment Adapt Rate Limit bits/int bits/int (ms) (bytes) Active Queue Packets Bytes Packets Bytes Shaping Depth Delayed Delayed Active no Essa condição resulta da classificação do pacote de saída, que ocorre no caminho de switching do CEF e novamente quando o processo de criptografia retira o pacote da fila. Este problema é resolvido nos estes o Bug da Cisco ID. CSCdu17976 (clientes registrados somente) - Resolve este problema adicionando uma bandeira que marque o pacote como já sendo classificado. CSCdv79109 (clientes registrados somente) - Mainline do CEF switching e do Cisco IOS Software Release CSCdt62225 (clientes registrados somente) - Interruptor rápido e mainline do Cisco IOS Software Release Além, quando os túneis GRE e o IPsec são configurados, um pacote é executado duas vezes com o processo de consulta CEF, uma vez após o encapsulamento de GRE e uma vez após o encapsulamento de IPSec. Como o pacote é transmitido somente após o encapsulamento do IPSec, ocorre falha no balanceamento de carga de CEF por pacote, de modo que os pacotes usam sempre a mesma interface. Criptografia de software e Switching rápida/cef

14 Quando usar criptografia de software, recurso pré-classificado QoS e CBWFQ, os pacotes comutados rápidos podem não estar classificados adequadamente. Este problema é considerado na saída do comando show policy-map interface: 3640-ch1#show policy-map interface {snip} Class-map: precedence (match-all) 5 packets, 520 bytes --- Five packets matched the class. 30 second offered rate 0 bps, drop rate bps Match: ip precedence 5 Weighted Fair Queueing Output Queue: Conversation 26 Bandwidth 10 (%) Bandwidth 1 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 11756/ Many packets actually are queued. (depth/total drops/no-buffer drops) 63/6359/0 Como uma ação alternativa, use um módulo de criptografia de hardware, force o processo que comuta com o comando no ip route-cache cef, ou desabilite a pré-classificação de QoS. Isso faz o sistema de enfileiramento moderado ver um único fluxo criptografado na classe de padrão classe. Esse problema é resolvido no bug Cisco ID CSCdw28771 (apenas clientes registrados). Legado de filas de prioridade e pré-classificação de QoS Os recursos de enfileiramento de prioridade legado de Cisco, que usam os comandos priority-list and priority-group, e a característica da préclassificação de QoS não são apoiados junto. Em lugar de, implementar LLQ configurando um mapa de política com o comando priority do MQC. Criptografia de hardware e QoS Estas são questões solucionadas com criptografia de hardware e QoS. Identificação de bug Cisco CSCdv25358 (clientes registrados somente) - Quando você usa o comando rate-limit executar o Policiamento de tráfego através da característica do Committed Access Rate (CAR) do legado Cisco, o comando qos pre-classify não trabalha quando a criptografia de hardware é usada igualmente. Essa combinação de recursos impede a criptografia. Como uma ação alternativa, class-based policing do implementar com a ajuda do comando police em um mapa de política configurado com a interface de linha do comando modular qos (CLI) (MQC). Os demais recursos de QoS (MQC ou não-mqc) não são afetados. Identificação de bug Cisco CSCdw29595 (clientes registrados somente) - O desempenho do caminho de criptografia degrada quando o Cisco IOS Software Release 12.2(6.8) é usado com uma placa de criptografia do hardware. A perda em desempenho ocorre porque pacotes criptografados são comutados por processo em vez de serem comutados rapidamente. Esta condição ocorre quando o IPSec é aplicado às interfaces enquanto a placa de criptografia de hardware é usada. Não há solução. Identificação de bug Cisco CSCdw30566 (clientes registrados somente) - Em um IPsec com ambiente de GRE, se você permite o CEF, conduz ao desempenho de encaminhamento reduzido desde que os pacotes são realmente comutados por processo. Esta circunstância resulta de como pacotes processados CEF depois que GRE-foram encapsulados. Como uma ação alternativa, desabilite o CEF, e permita que os pacotes sejam fast-switched. Quando você usa aceleradores de criptografia, veja a seção dos pacotes da classificação deste documento e o exame das mudanças executadas no Bug da Cisco ID CSCdw90486 (clientes registrados somente) e CSCdx08427 (clientes registrados somente). Informações Relacionadas RFC Arquitetura de segurança para o protocolo da Internet RFC Cabeçalho de autenticação RFC 2406 Payload de segurança de encapsulamento (ESP) de IP Configurando e pesquisando defeitos a criptografia de camada de rede Cisco: Fundo - Parte 1 Notas Técnicas de Troubleshooting Cisco Systems Inc. Todos os direitos reservados. Data da Geração do PDF: 16 Janeiro