3.7 ECN Explicit Congestion Notification
3.7.4 Vulnerabilidades de ECN
Nesta se¸c˜ao, s˜ao descritas as vulnerabilidades de ECN em v´arios cen´arios [134]. Na primeira subse¸c˜ao, ´e discutido como ECN pode influenciar na detec¸c˜ao e penaliza¸c˜ao dos fluxos n˜ao reagem `a indica¸c˜ao de congestionamento, seja por que s˜ao fluxos n˜ao adapta- tivos ou mal comportados ou ainda fluxos que possuem suporte a ECN mas n˜ao seguem as regras de ECN. Na segunda subse¸c˜ao, ser˜ao tratados os problemas que a altera¸c˜ao dos bits ECN pode causar.
Fluxos Mal Comportados
O problema de se detectar e penalizar tr´afegos n˜ao adaptativos ou mal comportados que n˜ao diminuem sua taxa de transmiss˜ao diante de congestionamentos ´e um problema bas- tante conhecido. Para tratar deste problema, sugere-se que sejam desenvolvidos mecanis- mos para detectar e eventualmente penalizar estes fluxos mal comportados na presen¸ca de congestionamento. Tais mecanismos incluem desde coleta e armazenamento de in- forma¸c˜oes por fluxo, escalonamento por fluxo, isolamento dos fluxos, servi¸cos diferenciados e reserva de recursos. Estes mecanismos usados de forma isolada ou em conjunto podem minimizar ou eventualmente remover os problemas que estes tr´afegos podem causar.
A penalidade aplicada aos fluxos mal comportados ´e, geralmente, o descarte dos pa- cotes destes fluxos. Assim, pode-se pensar que com ECN estes fluxos possam ser favoreci- dos ao inv´es de serem penalizados j´a que seus pacotes n˜ao ser˜ao descartados. No entanto, isto n˜ao ´e de fato o que acontece devido a trˆes raz˜oes:
• O comportamento dos roteadores em descartar pacotes se mant´em quando o con-
gestionamento ´e intenso. Quando o congestionamento ´e incipiente, a presen¸ca de fluxos mal-comportados n˜ao ´e t˜ao nociva, uma vez que h´a banda suficiente para todos os fluxos. O problema ocorre quando o congestionamento ´e intenso, j´a que estes fluxos ir˜ao prejudicar os fluxos adaptativos, conseguindo uma parte da banda bem maior que os demais;
• O descarte de pacotes utilizado como ´unica maneira de penalizar ou controlar fluxos
mal comportados n˜ao ´e eficiente;
• Fluxos sens´ıveis ao atraso e que usam transmiss˜ao n˜ao confi´avel, incrementam o uso
de FEC -Forward Error Correction, em resposta ao aumento da taxa de descarte, aumentando assim a sua taxa de transmiss˜ao ao inv´es de diminu´ı-la.
Mudan¸cas dos Bits do Cabe¸calho IP e TCP
Nas Se¸c˜oes 3.7.2 e 3.7.3, foram apresentados os bits utilizados por ECN tanto no cabe¸calho IP como no cabe¸calho TCP, como tamb´em o seu significado. Atrav´es da utiliza¸c˜ao destes bits ´e poss´ıvel indicar se um n´o possui suporte a ECN. O roteador pode marcar um pacote de um fluxo indicando a existˆencia do congestionamento; o receptor pode reportar este congestionamento ao emissor e, este, por sua vez pode informar que j´a reagiu ao con- gestionamento. Caso alguns destes bits sejam alterados intencionalmente pelos usu´arios ou por algum problema encontrado no caminho percorrido pelo pacote, ECN pode n˜ao funcionar a contento, conseq¨uentemente n˜ao atingindo os seus objetivos.
A seguir s˜ao apresentados os problemas causados quando estes bits s˜ao alterados. Falsa Indica¸c˜ao de Suporte a ECN: foi visto na Se¸c˜ao 3.7.2 que um n´o faz a in-
dica¸c˜ao de suporte a ECN atrav´es do campo ECT(0) ou ECT(1). Suponha que um pacote possui um destes campos, mas o protocolo de transporte utilizado para transmitir este pacote n˜ao possui suporte a ECN. Se este pacote encontra no seu caminho congestionamento moderado e passa por um roteador com suporte a ECN, este roteador ir´a marcar o campo CE deste pacote ao inv´es de descart´a-lo. Como o protocolo de transporte n˜ao possui suporte a ECN, ir´a ignorar a notifica¸c˜ao de congestionamento e n˜ao ir´a reduzir a sua taxa de transmiss˜ao;
Desabilitando a Indica¸c˜ao de Suporte a ECN: este caso ´e justamente o oposto do anterior. Um pacote tinha um dos campos ECT(0) ou ECT(1) e foi modificado, ficando com o campo Not-ECN. Caso este pacote encontre algum congestionamento no seu caminho, mesmo que o roteador tenha suporte a ECN, ele ser´a descartado ao inv´es de ser marcado, pois o roteador n˜ao ter´a como saber que ele tamb´em possu´ıa suporte a ECN;
Falsa Indica¸c˜ao de Congestionamento: quando um roteador recebe um pacote que
possui suporte a ECN e existe um congestionamento incipiente, o roteador marca este pacote com o campo CE ao inv´es de descart´a-lo para que seja feita a indica¸c˜ao de congestionamento ao emissor, para que este diminua a sua taxa de transmiss˜ao. Um usu´ario mal intencionado pode fazer um ataque deny of service, justamente enviando para o receptor em nome do emissor um pacote com o campo CE, ou ainda o pr´oprio receptor tamb´em pode fazer este ataque marcando o bit ECN-Echo no seu cabe¸calho TCP. Com isto, o emissor ir´a reduzir sua taxa de transmiss˜ao em resposta a uma notifica¸c˜ao de congestionamento falsa;
Remo¸c˜ao da Indica¸c˜ao de Congestionamento: caso um pacote estivesse com o campo
CE marcado e este campo por algum motivo foi removido, o receptor n˜ao poder´a informar ao emissor a existˆencia de congestionamento, o que poder´a agravar ainda mais o quadro de congestionamento existente. Caso a altera¸c˜ao n˜ao tenha sido do campo CE, mas do flag ECN-Echo de um ACK, o problema n˜ao ´e t˜ao grave, pois mesmo que um ACK tenha sido alterado, o receptor continua enviando ACK’s com o flag ECN-Echo marcado at´e que receba do emissor um pacote com o flag CWR marcado.