О документе
Рабочая группа Network Working Group F. Baker
Запрос на комментарии: 3704 Cisco Systems
Обновляет: 2827 P. Savola
BCP: 84 CSC/FUNET
Категория: Лучшая современная практика Март 2004
Входная фильтрация для мультидомных сетей
1. Введение
BCP 38, RFC 2827 [1], предназначен для ограничения воздействия
распределённых атак отказа в обслуживании путём отказа трафику с
подменёнными адресами в доступе к сети, а также для содействия
обеспечению возможности проследить трафик до его правильной исходной
сети. Побочным эффектом защиты Интернета от таких атак является то,
что сеть, реализующая это решение, также защищает себя от этой и
других атак, таких как подменённый доступ к управлению сетевым
оборудованием. В некоторых случаях это может создавать проблемы,
например при мультидоминге. Этот документ описывает текущие
эксплуатационные механизмы входной фильтрации, рассматривает общие
вопросы, связанные с входной фильтрацией, и подробно исследует, в
частности, влияние на мультидоминг.
RFC 2827 рекомендует, чтобы ISP контролировали трафик своих клиентов,
отбрасывая трафик, входящий в их сети с адреса источника, который
законно не используется сетью клиента. Фильтрация включает, но никоим
образом не ограничивается трафиком, адресом источника которого является
так называемый «марсианский адрес» ("Martian Address") — адрес,
зарезервированный [3], включая любой адрес в пределах 0.0.0.0/8,
10.0.0.0/8, 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/4
или 240.0.0.0/4.
Обоснование процедуры входной фильтрации состоит в том, что
распределённые атаки отказа в обслуживании часто подменяют адреса
источников других систем, помещая в это поле случайное число. В
некоторых атаках это случайное число детерминированно находится в
целевой сети, одновременно атакуя одну или несколько машин и вызывая
у этих машин атаки на другие с помощью сообщений ICMP или другого
трафика; в этом случае атакуемые площадки могут защитить себя
надлежащей фильтрацией, проверяя, что их префиксы не используются в
адресах источника пакетов, получаемых из Интернета. В других атаках
адрес источника буквально является случайным 32-битным числом, из-за
чего источник атаки трудно отследить. Если трафик, покидающий
периферийную сеть и входящий в ISP, можно ограничить трафиком, который
она законно отправляет, атаки можно несколько смягчить: трафик со
случайными или неправильными адресами источника можно подавить до того,
как он нанесёт значительный ущерб, а атаки можно без труда отследить
как минимум до их исходных сетей.
Этот документ предназначен для операторов ISP и периферийных сетей,
которые: 1) хотели бы узнать больше о методах входной фильтрации в
целом или 2) уже в некоторой степени используют входную фильтрацию,
но хотели бы расширить её применение и хотят избежать подводных
камней входной фильтрации в сценариях мультидоминга/асимметрии.
В разделе 2 описаны и рассмотрены несколько различных способов
реализации входной фильтрации в общем контексте. В разделе 3 сделаны
некоторые уточнения относительно применимости методов входной
фильтрации. В разделе 4 входная фильтрация подробно анализируется с
точки зрения мультидоминга. В разделе 5 определены выводы и возможные
направления дальнейшей работы.
2. Различные способы реализации входной фильтрации
Этот раздел служит введением в различные эксплуатационные методы,
используемые для реализации входной фильтрации на момент написания
этого меморандума. Механизмы описаны и проанализированы в общих
терминах, а вопросы, специфичные для мультидоминга, описаны в разделе 4.
Существует как минимум пять способов реализации RFC 2827 с различным
влиянием. Они включают следующее (эти названия относительно
распространены):
o Списки доступа на входе
o Строгая пересылка по обратному пути
o Пересылка по обратному пути допустимого маршрута
o Нестрогая пересылка по обратному пути
o Нестрогая пересылка по обратному пути с игнорированием маршрутов
по умолчанию
Возможны и другие механизмы, и действительно существует ряд методов,
которым могли бы быть полезны дальнейшее изучение, спецификация,
реализация и/или развёртывание; см. раздел 6. Однако они выходят за
рамки настоящего документа.
2.1. Списки доступа на входе
Список доступа на входе — это фильтр, который сверяет адрес источника
каждого сообщения, полученного на сетевом интерфейсе, со списком
допустимых префиксов, отбрасывая любой пакет, не соответствующий
фильтру. Хотя это далеко не единственный способ реализации входного
фильтра, именно он предложен RFC 2827 [1] и в некотором смысле является
наиболее детерминированным.
Однако списки доступа на входе обычно поддерживаются вручную; например,
если забыть обновить список у ISP при изменении набора префиксов
(например, вследствие мультидоминга), это может привести к отбрасыванию
пакетов, если они не проходят входной фильтр.
Разумеется, эта проблема не ограничивается списками доступа на входе —
она присуща входной фильтрации, когда входной фильтр неполон. Однако
обычно списки доступа на входе труднее поддерживать, чем другие
механизмы, а наличие устаревшего списка может препятствовать законному
доступу.
2.2. Строгая пересылка по обратному пути
Строгая пересылка по обратному пути (Strict Reverse Path Forwarding,
Strict RPF) — простой способ реализации входного фильтра. Концептуально
она идентична использованию списков доступа для входной фильтрации, за
исключением того, что список доступа является динамическим. Её также
можно использовать во избежание дублирования конфигурации (например,
одновременного ведения статических маршрутов или фильтров BGP
prefix-list и списков доступа интерфейсов). Процедура состоит в том,
что адрес источника ищется в базе информации пересылки (Forwarding
Information Base, FIB) и, если пакет получен на интерфейсе, который
использовался бы для пересылки трафика к источнику пакета, он проходит
проверку.
Строгая пересылка по обратному пути является весьма разумным подходом
перед периферийной сетью любого типа; в частности, она значительно
превосходит списки доступа на входе, когда граница сети анонсирует
несколько префиксов с помощью BGP. Она создаёт простой, недорогой,
быстрый и динамический фильтр.
Но у строгой пересылки по обратному пути есть и собственные проблемы.
Во-первых, проверка применима только там, где маршрутизация симметрична
— где IP-датаграммы в одном направлении и ответы с другого
детерминированно следуют одним и тем же путём. Хотя это обычно для
интерфейсов периферийной сети, соединяющих её с ISP, это вовсе не
обычно между ISP, которые обычно используют асимметричную маршрутизацию
«горячей картошки» ("hot potato"). Кроме того, если BGP переносит
префиксы, но некоторые законные префиксы не анонсируются либо не
принимаются ISP в соответствии с его политикой, результат тот же,
что и при входной фильтрации с использованием неполного списка доступа:
часть законного трафика фильтруется из-за отсутствия маршрута в базе
информации пересылки маршрутизатора, выполняющего фильтрацию.
Существуют эксплуатационные методы, особенно для BGP, но в некоторой
степени применимые и к другим протоколам маршрутизации, которые
позволяют строгой RPF лучше работать в случае асимметричного или
мультидомного трафика. ISP назначает более предпочтительную метрику,
не распространяемую за пределы маршрутизатора: либо зависящий от
поставщика «вес» ("weight"), либо расстояние протокола, чтобы
предпочитать непосредственно полученные маршруты. При наличии BGP и
достаточной инфраструктуры настройку предпочтений можно было бы даже
автоматизировать, используя BGP Communities [2]. Таким образом маршрут
всегда будет наилучшим в FIB, даже в сценариях, в которых использовалась
бы только основная связность и обычно через интерфейс не проходили бы
никакие пакеты.
Этот метод предполагает отсутствие строгой RPF-фильтрации между
основным и резервным периферийными маршрутизаторами; в частности,
при применении к мультидомингу у разных ISP это предположение может
не выполняться.
2.3. Пересылка по обратному пути допустимого маршрута
Пересылка по обратному пути допустимого маршрута (Feasible Path
Reverse Path Forwarding, Feasible RPF) является расширением строгой
RPF. Адрес источника по-прежнему ищется в FIB (либо в эквивалентной
таблице, специфичной для RPF), но вместо внесения туда только одного
наилучшего маршрута добавляются также альтернативные пути (если они
есть), и они допустимы для рассмотрения. Список заполняется методами,
специфичными для протокола маршрутизации, например путём включения
всех или N (где N меньше общего числа) допустимых путей BGP в базу
информации о маршрутизации (Routing Information Base, RIB). Иногда
этот метод был реализован как часть реализации строгой RPF.
В случае асимметричной маршрутизации и/или мультидоминга на границе
сети этот подход предоставляет способ относительно легко устранить
наиболее серьёзные проблемы строгой RPF.
Критически важно понимать контекст, в котором работает Feasible RPF.
Этот механизм опирается на согласованные анонсы маршрутов (то есть
одни и те же префикс(ы) по всем путям), распространяющиеся до всех
маршрутизаторов, выполняющих проверку Feasible RPF. Например, это
может не соблюдаться в случае, когда резервный ISP не передаёт
анонс BGP основному ISP, например вследствие неактуальных route-maps
или иных политик маршрутизации. Режимы отказа обычно сходны с
«эксплуатационно улучшенной строгой RPF», описанной выше.
В качестве общего указания: если анонс фильтруется, пакеты также будут
фильтроваться.
Следовательно, при надлежащем определении Feasible RPF является очень
мощным средством в некоторых видах сценариев асимметричной
маршрутизации, но важно лучше понимать её эксплуатационную роль и
применимость.
2.4. Нестрогая пересылка по обратному пути
Нестрогая пересылка по обратному пути (Loose Reverse Path Forwarding,
Loose RPF) алгоритмически подобна строгой RPF, но отличается тем, что
проверяет только существование маршрута (включая маршрут по умолчанию,
если он применим), а не то, куда указывает маршрут. На практике это
можно считать «проверкой наличия маршрута» ("route presence check")
(«Loose RPF» в некотором смысле является неудачным названием, поскольку
прежде всего вообще не выполняется проверка «обратного пути»).
Сомнительная польза Loose RPF проявляется в ситуациях асимметричной
маршрутизации: пакет отбрасывается, если маршрута вообще нет, например
к «марсианским адресам» или адресам, которые в настоящее время не
маршрутизируются, но не отбрасывается, если маршрут существует.
Однако у Loose Reverse Path Forwarding есть проблемы. Поскольку он
жертвует направленностью, в большинстве случаев он утрачивает
способность ограничивать трафик граничной сети трафиком, законно
исходящим из этой сети, что делает этот механизм бесполезным как
механизм фильтрации входящего трафика.
Кроме того, многие ISP используют маршруты по умолчанию для различных
целей, таких как сбор неправомерного трафика в так называемых системах
«Honey Pot» или отбрасывание любого трафика, к которому у них нет
«реального» маршрута, а небольшие ISP вполне могут приобретать
возможности транзита и использовать маршрут по умолчанию от более
крупного поставщика. По меньшей мере некоторые реализации Loose RPF
проверяют, куда указывает маршрут по умолчанию. Если маршрут указывает
на интерфейс, где включён Loose RPF, с этого интерфейса разрешается
любой пакет; если он никуда не указывает или указывает на какой-либо
другой интерфейс, пакеты с поддельными адресами источника будут
отброшены на интерфейсе Loose RPF даже при наличии маршрута по
умолчанию. Если такая детальная проверка не реализована, наличие
маршрута по умолчанию полностью сводит на нет действие Loose RPF.
Одним из случаев, где Loose RPF мог бы хорошо подойти, могла бы быть
фильтрация ISP пакетов от его вышестоящих поставщиков, чтобы избавиться
от пакетов с «марсианскими» или другими немаршрутизируемыми адресами.
Если другие подходы не подходят, loose RPF мог бы использоваться как
форма проверки соблюдения договора: предполагается, что другая сеть
удостоверяет, что она предоставила надлежащие правила фильтрации
входящего трафика, поэтому сети, выполняющей фильтрацию, достаточно
лишь проверить этот факт и отреагировать, если будут обнаружены какие-
либо пакеты, свидетельствующие о нарушении договора. Разумеется, этот
механизм покажет лишь, используются ли адреса источника, являющиеся
«марсианскими» или другими немаршрутизируемыми адресами, — но не то,
принадлежат ли они адресному пространству кого-либо другого.
2.5. Loose Reverse Path Forwarding, игнорирующая маршруты по умолчанию
Пятый метод реализации можно охарактеризовать как Loose RPF,
игнорирующую маршруты по умолчанию, то есть «явную проверку наличия
маршрута». В этом подходе маршрутизатор ищет адрес источника в таблице
маршрутизации и сохраняет пакет, если маршрут найден. Однако при этом
поиске маршруты по умолчанию исключаются. Поэтому этот метод в
основном применим в сценариях, где маршруты по умолчанию используются
только для перехвата трафика с поддельными адресами источника, при
наличии обширного (или даже полного) списка явных маршрутов для
охвата законного трафика.
Как и Loose RPF, это полезно там, где присутствует асимметричная
маршрутизация, например на меж-ISP-каналах. Однако, как и Loose RPF,
поскольку этот метод жертвует направленностью, он утрачивает
способность ограничивать трафик граничной сети трафиком, законно
исходящим из этой сети.
3. Уточнение применимости фильтрации входящего трафика
Может быть не сразу очевидно, что фильтрация входящего трафика
применяется не только на интерфейсе «последней мили» между ISP и
конечным пользователем. Вполне допустимо и рекомендуется также
выполнять фильтрацию входящего трафика на границах ISP, где это
уместно, на маршрутизаторах, соединяющих LAN с сетью предприятия, и
т. д. — это усиливает многоуровневую защиту.
3.1. Фильтрация входящего трафика на нескольких уровнях
Из-за более широкого развёртывания фильтрации входящего трафика этот
вопрос носит рекурсивный характер. Фильтрация входящего трафика должна
работать везде, где она используется, а не только между первыми двумя
сторонами. То есть если пользователь согласовывает со своим ISP особую
схему фильтрации входящего трафика, он также должен обеспечить (или
удостовериться, что ISP обеспечивает), чтобы те же схемы применялись
и к вышестоящим и пиринговым каналам ISP, если там используется
фильтрация входящего трафика — или будет использоваться в какой-либо
момент в будущем; аналогично для вышестоящих ISP и пиров.
Следовательно, ручные модели, которые не распространяют автоматически
информацию всем сторонам, через которые будут проходить пакеты и где
может применяться фильтрация входящего трафика, имеют лишь
ограниченную общую полезность.
3.2. Фильтрация входящего трафика для защиты собственной инфраструктуры
Ещё одна особенность, возникающая вследствие более широкого
развёртывания фильтрации входящего трафика, может быть не сразу
очевидна. Маршрутизаторы и другая инфраструктура ISP уязвимы для
нескольких видов атак. Угроза обычно смягчается ограничением круга
лиц, которые могут получать доступ к этим системам.
Однако, если фильтрация входящего трафика (или по меньшей мере её
ограниченное подмножество) не развёрнута на каждой границе (в сторону
клиентов, пиров и вышестоящих поставщиков) — блокируя использование
собственных адресов в качестве адресов источника, — злоумышленники
могут суметь обойти средства защиты инфраструктурного оборудования.
Поэтому, развёртывая фильтрацию входящего трафика, организация не
только помогает Интернету в целом, но и защищается от нескольких
классов угроз собственной инфраструктуре.
3.3. Фильтрация входящего трафика на пиринговых каналах
Фильтрация входящего трафика на пиринговых каналах, выполняемая ли
ISP или конечными площадками, на самом деле не слишком отличается от
более типичной «нисходящей» или «восходящей» фильтрации входящего
трафика.
Однако важно отметить, что при смешанных восходящих/нисходящих и
пиринговых каналах различные каналы могут иметь разные свойства
(например, связанные с договорами, доверием, применимостью механизмов
фильтрации входящего трафика и т. д.). В наиболее типичном случае
простое использование механизма фильтрации входящего трафика в сторону
пира (например, Strict RPF) вполне работает, пока маршрутизация между
пирами поддерживается достаточно симметричной. Может даже считаться
полезной возможность отфильтровывать адреса источника, поступающие с
восходящего канала, которые должны были поступить по пиринговому каналу
(что подразумевает использование в сторону вышестоящего поставщика
чего-то вроде Strict RPF), — но это более сложная тема и считается
выходящей за рамки настоящего документа; см. Раздел 6.
4. Решения для фильтрации входящего трафика при мультихоминге
Прежде всего следует спросить, почему площадка использует
мультихоминг; например, граничная сеть может:
o использовать два ISP для резервирования подключения к Интернету с
целью обеспечения устойчивости,
o использовать того ISP, который в данный момент предлагает наиболее
быстрый сервис TCP,
o нуждаться в нескольких точках доступа к Интернету в местах, где ни
один ISP не предоставляет услуг, или
o менять ISP (и поэтому использовать мультихоминг лишь временно).
Можно представить ряд подходов к обходу ограничений фильтров входящего
трафика для мультидомных сетей. Варианты включают:
1. Не использовать мультихоминг.
2. Не использовать фильтры входящего трафика.
3. Принять неполноту сервиса.
4. На некоторых интерфейсах ослабить фильтрацию входящего трафика,
используя подходящую форму проверки loose RPF, как описано в
Разделе 4.1.
5. Обеспечить посредством BGP или договора полноту фильтра входящего
трафика каждого ISP, как описано в Разделе 4.2.
6. Обеспечить, чтобы граничные сети передавали своим ISP только тот
трафик, который фактически пройдёт фильтр входящего трафика, как
описано в Разделе 4.3.
Первые три из них очевидно упомянуты для полноты; они не являются и не
могут являться жизнеспособными позициями; последние три рассматриваются
ниже.
Четвёртый и пятый варианты должны быть обеспечены также в вышестоящих
ISP, как описано в Разделе 3.1.
Далее мы рассмотрим жизнеспособные способы устранения побочных эффектов
фильтров входящего трафика.
4.1. Использование Loose RPF, когда это уместно
Там, где асимметричная маршрутизация предпочтительна или неизбежна,
фильтрацию входящего трафика может быть трудно развернуть с помощью
такого механизма, как strict RPF, который требует симметричности
путей. Во многих случаях использование операционных методов или
feasible RPF может обеспечить полноту фильтра входящего трафика, как
описано ниже. Если это не удаётся, единственные реальные варианты — не
выполнять фильтрацию входящего трафика, использовать ручной список
доступа (возможно, в дополнение к некоторым другим механизмам) либо
использовать некоторую форму проверки Loose RPF.
Отсутствие какого-либо фильтра входящего трафика по существу означает
доверие к тому, что нисходящая сеть будет вести себя надлежащим образом,
что не является самым мудрым способом действий. Однако, особенно в
случае очень больших сетей, включающих даже сотни или тысячи префиксов,
поддержание ручных списков доступа может быть чрезмерным требованием.
Использование Loose RPF не представляется хорошим выбором между
граничной сетью и ISP, поскольку оно утрачивает направленность
проверки. Это свидетельствует в пользу либо использования полного
фильтра в вышестоящей сети, либо обеспечения в нисходящей сети того,
что пакеты, которые вышестоящая сеть отклонит, никогда не достигнут её.
Поэтому использование Loose RPF не может быть рекомендовано, кроме как
в качестве способа измерить, используются ли «марсианские» или другие
немаршрутизируемые адреса.
4.2. Обеспечение полноты фильтра входящего трафика каждого ISP
Для граничной сети, если мультихоминг используется для устойчивости или
для периодического изменения маршрутизации в зависимости от измеренного
поведения ISP, простейшим подходом будет обеспечить, чтобы её ISP
действительно переносили её адреса в маршрутизации. Это часто потребует
от граничной сети использовать независимые от поставщика префиксы и
обмениваться маршрутами со своими ISP посредством BGP, чтобы обеспечить
передачу её префикса вверх по сети к крупным транзитным ISP. По
необходимости это подразумевает, что граничная сеть будет иметь размер
и техническую компетентность, достаточные для получения от своего RIR
отдельного выделения адресов и номера автономной системы.
Существует ряд методов, упрощающих обеспечение полноты фильтра
входящего трафика ISP. Feasible RPF и Strict RPF с операционными
методами оба достаточно хорошо работают для мультидомных или
асимметричных сценариев между ISP и граничной сетью.
Когда протокол маршрутизации не используется, а информация о клиентах
вместо этого формируется из баз данных, таких как Radius, TACACS или
Diameter, фильтрацию входящего трафика легче всего обеспечить и
поддерживать в актуальном состоянии с помощью Strict RPF или списков
доступа для входящего трафика, автоматически создаваемых из таких баз
данных.
4.3. Передача трафика с префиксом поставщика только этому поставщику
Для небольших граничных сетей, использующих адресацию на основе
поставщика и чьи ISP реализуют фильтры входящего трафика (что им
следует делать), третий вариант состоит в маршрутизации трафика,
исходящего из адресного пространства данного поставщика, к этому
поставщику.
Это несложная процедура, но она требует тщательного планирования и
настройки. Для устойчивости граничная сеть может выбрать подключение к
каждому из своих ISP через две или более разных точек присутствия
(POP), чтобы в случае сбоя одного POP или линии можно было использовать
другое соединение с тем же ISP. В качестве альтернативы вместо
нескольких подключений к одному и тому же ISP может быть настроен набор
туннелей [4][5]. Таким образом, граничные маршрутизаторы настраиваются
сначала проверять адрес источника пакета, предназначенного для ISP, и
направлять его в соответствующий туннель или интерфейс в сторону ISP.
Если такой сценарий применяется исчерпывающе, так что для каждого
используемого сетью префикса в граничной сети выбирается выходной
маршрутизатор, трафик, исходящий из любого другого префикса, можно
сразу отбросить вместо отправки его ISP.
5. Вопросы безопасности
Фильтрация входящего трафика обычно выполняется для обеспечения того,
чтобы трафик, поступающий на один сетевой интерфейс, законно исходил от
компьютера, находящегося в сети, достижимой через этот интерфейс.
Чем ближе к фактическому источнику выполняется фильтрация входящего
трафика, тем она эффективнее. Можно было бы пожелать, чтобы
маршрутизатор первого перехода обеспечивал правильную адресацию
трафика, исходящего от соседней с ним конечной системы; более удалённый
маршрутизатор может обеспечить лишь возможность существования такой
системы в указанном префиксе. Поэтому фильтрацию входящего трафика
следует выполнять на нескольких уровнях с различной степенью
детализации.
Следует помнить, что, хотя одна из целей фильтрации входящего трафика —
сделать атаки отслеживаемыми, невозможно знать, фильтруется ли входящий
трафик конкретного злоумышленника «где-то в Интернете». Поэтому можно
лишь предполагать, были ли подделаны адреса источника: в любом случае
получение возможной зацепки — например, чтобы связаться с потенциальным
источником и спросить, наблюдает ли он атаку, — всё равно ценно и тем
более ценно, чем шире и шире развёртывается фильтрация входящего
трафика.
Следовательно, каждый административный домен должен стремиться
обеспечить достаточный уровень фильтрации входящего трафика на своих
границах.
Свойства безопасности и применимость различных типов фильтрации
входящего трафика сильно различаются.
o Списки доступа на входе обычно требуют ручного сопровождения, но при
надлежащем выполнении являются наиболее надёжным средством;
как правило, списки доступа на входе лучше всего подходят между
периферией и ISP, когда конфигурация не слишком динамична и строгий
RPF не является вариантом, между ISP, если число используемых
префиксов невелико, либо в качестве дополнительного уровня защиты.
o Строгая проверка RPF — очень простой и надёжный способ реализовать
входную фильтрацию. Обычно она подходит между периферийной сетью и
ISP. Во многих случаях простую строгую RPF можно дополнить
эксплуатационными процедурами при асимметричных шаблонах трафика
либо методом Feasible RPF, чтобы также учитывать другие
альтернативные пути.
o Проверка Feasible Path RPF является расширением Strict RPF. Она
подходит во всех сценариях, в которых подходит Strict RPF, но в
особенности в многодомных или асимметричных сценариях. Однако
следует помнить, что для работы Feasible RPF предполагает
согласованное порождение и
распространение маршрутной информации; последствия этого должны
быть понятны, особенно если объявление префикса проходит через
третьи стороны.
o Loose RPF прежде всего отфильтровывает немаршрутизируемые префиксы,
такие как Martian-адреса. Его можно применять на интерфейсах
восходящего направления, чтобы уменьшить размер DoS-атак с
немаршрутизируемыми исходными адресами. На интерфейсах нисходящего
направления его можно использовать только для проверки договора:
что другая сеть выполнила хотя бы некоторую входную фильтрацию.
При взвешивании компромиссов различных механизмов входной фильтрации
перед применением более ослабленного подхода следует тщательно
рассмотреть его свойства безопасности. В особенности при применении
ISP по отношению к периферийной сети, по-видимому, существует немного
причин, по которым более строгая форма входной фильтрации не была бы
уместна.
6. Выводы и дальнейшая работа
Эта записка описывает методы входной фильтрации в целом и варианты для
многодомных сетей в частности.
ISP важно реализовать входную фильтрацию, чтобы предотвращать
использование подменённых адресов, как для ограничения DoS-атак и
повышения их прослеживаемости, так и для защиты собственной
инфраструктуры. Эта записка описывает механизмы, которые могли бы
использоваться для достижения такого эффекта, и компромиссы этих
механизмов.
Подводя итог:
o Входную фильтрацию всегда следует выполнять между ISP и
однодомной периферийной сетью.
o Входная фильтрация с Feasible RPF или сходными методами Strict RPF
почти всегда могла бы применяться также между ISP и многодомными
периферийными сетями.
o Как ISP, так и периферийным сетям следует проверять, что их
собственные адреса не используются в качестве исходных адресов в
пакетах, поступающих извне их сети.
o Некоторая форма входной фильтрации также разумна между ISP,
особенно если число префиксов невелико.
Эта записка снизит барьер для внедрения входной фильтрации, особенно в
таких сценариях, как асимметричные/многодомные сети, где общее мнение
состояло в том, что входную фильтрацию трудно реализовать.
Можно выделить несколько областей, в которых была бы полезна
дополнительная работа:
o Уточнить механизмы подробнее: между реализациями имеются некоторые
различия, например в том, всегда ли трафик к адресам назначения
многоадресной рассылки проходит фильтр Strict RPF или нет. При
формальном определении механизмов реализации могли бы быть
гармонизированы.
o Подробнее изучить и определить механизмы RPF на основе Routing
Information Base (RIB), например Feasible Path RPF. В частности,
рассмотреть, при каких предположениях эти механизмы работают как
задумано, а при каких — нет.
o Написать более общую записку о механизмах входной фильтрации, чем
эта записка, после того как будут проработаны таксономия и детали
или механизмы (указанные выше пункты).
o Рассмотреть более сложный случай, когда сеть имеет подключение с
различными свойствами (например, пиры и восходящие провайдеры) и
хочет обеспечить, чтобы трафик с исходным адресом пира не
принимался от восходящего провайдера.
7. Благодарности
Rob Austein, Barry Greene, Christoph Reichert, Daniel Senie, Pedro
Roque и Iljitsch van Beijnum рассмотрели этот документ и помогли его
улучшить. Thomas Narten, Ted Hardie и Russ Housley предоставили
хорошие отзывы, которые способствовали доработке документа на его
заключительных этапах.
8.1. Нормативные ссылки
[1] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
8.2. Справочные ссылки
[2] Chandrasekeran, R., Traina, P. and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[3] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[4] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed
Multi-provider Connectivity", RFC 2260, January 1998.
[5] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit
Routers", RFC 3178, October 2001.
9. Адреса авторов
Fred Baker
Cisco Systems
Santa Barbara, CA 93117
US
EMail: fred@cisco.com
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
10. Полное заявление об авторском праве
Copyright (C) The Internet Society (2004). Этот документ подпадает под
права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением
изложенного в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на основе
"КАК ЕСТЬ", и ЛИЦО, ВНЕСШЕЕ ВКЛАД (CONTRIBUTOR), ОРГАНИЗАЦИЯ, КОТОРУЮ
ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ),
INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ
ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ
ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ
КАКИХ-ЛИБО ПРАВ, ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ
ИЛИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.