Протоколы маршрутизации AODV и SAODV
Уязвимость радиоканалов и узлов, отсутствие фиксированной инфраструктуры и частые изменения топологии сети делают неприменимыми для самоорганизующихся сетей многие известные решения по защите от атак DoS маршрутизации. Ниже рассматривается один из таких эффективных протоколов маршрутизации, который принадлежит семейству реактивных протоколов [104]. Название этого протокола Ad Hoc on demand distance vector protocol (AODV), что переводится на русский язык как протокол маршрутизации по требованию на основе вектора расстояний. Протокол AODV специально разработан для MANET. В AODV узел, желающий переслать пакет узлу, к которому он еще не имеет пути в своей таблице маршрутизации, будет пытаться найти путь. Нахождение нового пути происходит с помощью рассылки по всей сети сообщения о запросе пути, которое называется RREQ (route request message). Таким образом, узел, желающий передать пакет другому узлу, посылает сообщение RREQ. Сообщение RREQ содержит IP-адрес отправителя и IP-адрес получателя сообщения, т.е. узла, с которым необходимо установить связь отправителю. RREQ распространяется по всей сети до того момента, когда найдется узел, знающий путь до получателя или найдется сам получатель. В этом случае в ответ будет послано сообщение о том, что путь найден. Это сообщение называется RREP (route reply message). RREP посылается обратным путем к отправителю. Во время обратной отсылки RREP устанавливается связь. В RREQ существует еще одно поле, которое называется время жизни (time to live) или TTL. Это поле устанавливается отправителем для того, чтобы иметь возможность определить и ограничить глубину путешествия пакета RREQ перед тем, как он найдет получателя. Таким образом, RREQ будет распространятся по сети до тех пор, пока количество уже посещенных пакетом узлов будет меньше, чем TTL.
Одно из полей этого сообщения называется количество посещенных узлов (hop-count field). Оно сообщает о количестве узлов посещенных пакетов до того, как он достиг текущего узла. В тот момент, когда узел получает RREQ, он проверяет количество уже посещенных узлов до того момента, как сообщение достигло его (hop count field). Затем он создает новый путь до отправителя RREQ сообщения (если только он не имеет уже более короткий путь) для того, чтобы иметь возможность использовать его для отправки RREP сообщения. Причем путь до отправителя от этого узла будет идти через узел, от которого было получено сообщение RREQ. Длина пути будет равна числу, содержащемуся в поле hop-count field полученного RREQ. Затем узел проверяет, знает ли он путь до получателя, IP-адрес которого содержится в RREQ.
Если узел, принявший RREQ, не знает путь до получателя, он увеличивает число в hop count field и переправляет RREQ своим соседям. Если RREQ получено узлом, который знает свежий путь до получателя или RREQ получено самим получателем, то узел отвечает отправителю RREQ сообщением RREP. Сообщение RREP посылается только начальному отправителю RREQ по пути, который был создан во время распространения сообщения RREQ. Сообщение RREP также содержит поле (hop count field), указывающее количество узлов от узла, сгенерировавшего RREP до получателя (причем 0 будет, если RREP генерируется самим получателем).
Это поле также увеличивается на один каждым узлом, переправляющим RREP по пути от получателя к отправителю. Поскольку каждый узел, который знает свежий путь к получателю, будет генерировать RREP, то к отправителю придет несколько сообщений RREP, которые будут указывать путь к получателю. Когда отправитель RREQ сообщения получает много RREP, он может сравнить их по полю hop count field, которое будет свидетельствовать о длине пути. Выбранным будет путь с наименьшим значением в hop count field. Опционно, отправитель RREQ сообщения может также посылать пакет, подтверждающий прием сообщения RREP, который называется RREP-ACK.
На рис. 26.4 показана работа протокола AODV. На этом рисунке отправитель А желает найти путь к получателю B. Узел А создает и распространяет сообщение RREQ. Узел B отвечает сообщением RREP после получения RREQ, используя уже созданный путь. Необходимость защиты протокола AODV от приведенных выше атак DoS нарушения маршрутизации потребовал его модифицировать. Этот протокол получил название безопасного протокола SAODV (Secure AODV). Он обеспечивает подлинность источника сообщений RREQ и RREP, целостность этих сообщений. В SAODV для этого предусмотрены механизмы цифровой подписи и хеш-цепей. Механизм цифровой подписи служит для защиты неизменяемых полей в сообщениях между узлами сети. Сообщения RREQ и RREP также содержат переменную информацию, которая должна изменяться после каждого узла. Это поле не подписывается отправителем служебного сообщения. Второй механизм (хеш-цепи) используется для защиты такой изменяемой информации, в качестве которой является счетчик скачков (хопов).
Рис. 26.4. Иллюстрация работы протокола AODV