RFC 8517 | Инвентаризация транспортно-ориентированных функций, предоставляемых промежуточными устройствами: взгляд оператора

Аннотация

В этом документе обобщается представление оператора о преимуществах, которые могут быть предоставлены промежуточными устройствами, которые выполняют функции, выходящие за рамки обычной IP-пересылки. Такие промежуточные устройства часто называют «промежуточными ящикамиmiddleboxes».

RFC 3234 определяет таксономию промежуточных ящиков и проблем в Интернете. Большинство из этих промежуточных блоков используют или изменяют данные уровня приложений. В этом документе основное внимание уделяется устройствам, которые наблюдают и обрабатывают информацию, передаваемую на транспортном уровне, и особенно информацию, переносимую в пакетах TCP.
Скачать оригинальный документ на английском языке RFC 8517 PDF

Оглавление

1. Введение
1.1. Перспектива оператора
1.2. Объем
2. Измерения
2.1. Потеря пакета
2.2. Время туда и обратно
2.3. Изменение порядка измерений
2.4. Пропускная способность и выявление узких мест
2.5. Отзывчивость
2.6. Обнаружение атаки
2.7. Пакетная коррупция
2.8. Измерения прикладного уровня
3. Функции за пределами измерения: несколько примеров
3.1. NAT
3.2. Брандмауэр
3.3. DDoS Scrubbing
3.4. Неявная идентификация
3.5. Улучшающие производительность прокси
3.6. Сетевое кодирование
3.7. Агрегирование полосы пропускания с помощью сети
3.8. Расстановка приоритетов и дифференцированные услуги
3.9. Формирование на основе измерений
3.10. Справедливость по отношению к квоте конечного пользователя
4. Соображения IANA
5. Вопросы безопасности
5.1. Конфиденциальность и конфиденциальность
5.2. Активные атаки на пути
5.3. Улучшенная безопасность
6. Информационные ссылки
Благодарности
Адреса авторов

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Это вклад в серию RFC, независимо от любого другого потока RFC. Редактор RFC решил опубликовать этот документ по своему усмотрению и не делает никаких заявлений о его ценности для внедрения или развертывания. Документы, одобренные для публикации редактором RFC, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 7841.

Информацию о текущем статусе этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8517.

Уведомление об авторских правах

Copyright (c) 2019 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

1. Введение

Из [RFC3234] «промежуточное окно определяется как любое промежуточное устройство, выполняющее функции, отличные от обычных, стандартных функций IP-маршрутизатора на пути дейтаграммы между исходным хостом и хостом назначения».

Промежуточные блоки обычно (но не исключительно) развертываются в местах, позволяющих наблюдать за двунаправленными потоками трафика. Такие местоположения обычно являются точками, где конечные сети подключаются к Интернету, например:

  • Когда жилой или бизнес-клиент подключается к своему поставщику (-ам) услуг, который может включать в себя множественную адресацию;
  • На интерфейсе Gi, где узел поддержки (GGSN) шлюза общей службы пакетной радиосвязи (GPRS) подключается к сети пакетной передачи данных (PDN) (раздел 3.1 [RFC6459]).

Для целей этого документа (и в соответствии с определением в RFC 3234) функции промежуточного ящика можно найти в маршрутизаторах и коммутаторах в дополнение к выделенным устройствам.

В этом документе перечислены различные функции, предоставляемые промежуточными модулями и специальным анализом, выполняемым операторами с использованием анализаторов пакетов.

Многие из методов, описанных в этом документе, требуют анализа транспортных потоков с учетом состояния. Общий конечный автомат описан в [PATH-STATE].

Этот документ суммирует восприятие оператором преимуществ, которые могут быть предоставлены промежуточными коробками. Основная цель — предоставить информацию интернет-сообществу, чтобы помочь понять, что может быть получено или потеряно в результате решений, которые могут повлиять (или быть затронуты) работой промежуточной коробки при разработке новых транспортных протоколов. См. Раздел 1.1 для более подробной информации.

1.1. Перспектива оператора

Сетевые операторы часто являются первыми, когда приложения не работают должным образом, часто с пользовательскими отчетами о поведении приложений (а не о поведении пакетов). Поэтому неудивительно, что операторы (желающие быть полезными) желают получить некоторую информацию о потоках, чтобы определить, насколько хорошо продвигаются проблемные потоки и насколько хорошо развиваются другие потоки.

Расширенные сервисные функции (например, трансляторы сетевых адресов (NAT), межсетевые экраны и т. д.) [RFC7498] широко используются для достижения различных целей, таких как совместное использование IP-адресов, межсетевые экраны, обход скрытых каналов, обнаружение и защита от постоянно растущего распределенного отказа в Атаки на услуги (DDoS) и т. Д. Например, для проектов, зависящих от среды, может потребоваться ряд сервисных функций, таких как те, которые необходимы в интерфейсе Gi мобильной инфраструктуры [USE-CASE].

Эти сложные сервисные функции расположены в сети, но также в сервисных платформах или промежуточных объектах (например, сети доставки контента (CDN)). Обслуживание сети и диагностические операции сложны, особенно когда ответственность разделена между различными игроками.

Перед сетевыми провайдерами стоит задача предоставлять дифференцированные услуги в качестве конкурентного бизнес-преимущества, одновременно осваивая сложность приложений, (непрерывно) оценивая влияние на промежуточные блоки и улучшая качество обслуживания клиентов.

Несмотря на сложность, удаление всех этих сервисных функций не вариант, потому что они используются для устранения ограничений, которые часто являются типичными для текущего (и меняющегося) Интернета. Операторы должны иметь дело с ограничениями, такими как глобальное истощение IPv4-адресов, и поддерживать множество сервисов с различными требованиями к QoS, безопасности, надежности и т. д.

1.2. Объем

Хотя многие промежуточные блоки наблюдают и управляют контентом прикладного уровня (например, контроллерами границы сеанса [RFC5853]), они выходят за рамки этого документа, целью которого является описание промежуточных блоков с использованием функций транспортного уровня. [RFC8404] описывает влияние повсеместного шифрования данных прикладного уровня на мониторинг, защиту и устранение неполадок сети.

Текущий документ не предназначен для того, чтобы рекомендовать (или запретить) развертывание промежуточного ящика. Многие операторы считают, что ценность промежуточных коробок перевешивает добавленную стоимость и сложность; этот документ пытается предоставить эту перспективу в качестве ссылки при обсуждении компромиссов дизайна протокола.

Этот документ не предназначен для обсуждения вопросов, связанных с промежуточными коробками. Эти проблемы хорошо известны и зафиксированы в существующих документах, таких как [RFC3234] и [RFC6269]. Этот документ направлен на развитие мотивации, побуждающей операторов к включению таких функций, несмотря на сложности.

В этом документе рассматривается точка зрения оператора на то, что измерение и управление транспортными соединениями выгодно обеим сторонам: конечный пользователь получает лучшее качество обслуживания, а сетевой оператор улучшает использование ресурсов, причем первое является следствием второго.

В этом документе не обсуждается, можно ли получить доступ к некоторым данным на подключенных устройствах для помощи сети, используя внутриполосные или внеполосные механизмы.

2. Измерения

Ряд измерений может быть выполнен сетевыми устройствами, которые находятся либо в пути, либо вне пути. Эти измерения могут использоваться либо автоматизированными системами, либо для ручного устранения неполадок в сети (например, с использованием инструментов анализа пакетов). Автоматизированные системы могут быть далее разделены на два типа: 1) системы мониторинга, которые вычисляют показатели эффективности для отдельных соединений или совокупностей соединений и генерируют из них агрегированные отчеты; и 2) активные системы, которые также принимают решения о том, как обрабатывать потоки пакетов на основе этих показателей эффективности.

Долгосрочные тенденции в этих измерениях могут помочь оператору в планировании мощности.

Кратковременные аномалии, выявленные этими измерениями, могут выявить обрывы сети, происходящие атаки или ненадлежащее поведение устройств / приложений.

2.1. Потеря пакета

Для оператора очень полезно иметь возможность обнаруживать и изолировать потерю пакетов в сети.

Проблемы с сетью и недостаточное обеспечение могут быть обнаружены, если потеря пакетов измерима. Потерю пакета TCP можно обнаружить, наблюдая пропуски в порядковых номерах, повторно передаваемых порядковых номерах и параметрах выборочного подтверждения (SACK) [RFC2018]. Потеря пакета может быть обнаружена в каждом направлении.

Пробелы указывают на потери до точки наблюдения за движением; повторные передачи указывают на потерю после точки наблюдения трафика. SACK могут использоваться для обнаружения потери пакетов в восходящем или нисходящем направлении (хотя необходимо соблюдать осторожность, чтобы избежать неправильного определения переупорядочения пакетов как потери пакетов) и для различения потерь в восходящем и нисходящем направлениях.

Измерения потери пакетов по обе стороны от точки измерения являются важным компонентом точной диагностики недостаточно измеренных устройств или каналов в сетях. Кроме того, потери пакетов являются одним из двух основных способов проявления перегрузки, другими являются задержка в очереди или явное уведомление о перегрузке (ECN) [RFC3168]; следовательно, потеря пакетов является важным измерением для любого промежуточного блока, которому необходимо принимать решения по обработке трафика на основе наблюдаемых уровней перегрузки.

2.2. Время туда и обратно

Способность измерять время прохождения сигнала в обоих направлениях (RTT) полезна для диагностики проблем в сети (например, ненормальной задержки, ненормальной потери пакетов). Знание, является ли задержка плохой на одной стороне точки наблюдения или другой, предоставляет больше информации, чем доступно на любой конечной точке, которая может наблюдать только полные RTT.

Например, поток пакетов TCP может использоваться для измерения RTT на каждой стороне точки измерения. Во время установления соединения могут использоваться значения синхронизации SYN, SYN / ACK и ACK для установления базового RTT в каждом направлении. Как только соединение установлено, RTT между сервером и точкой измерения может быть надежно определен только с использованием временных меток TCP [RFC7323]. На стороне между точкой измерения и клиентом в качестве альтернативы можно использовать точную синхронизацию сегментов данных и ACK. Чтобы этот последний метод был точным при наличии потери пакетов, соединение должно использовать выборочные подтверждения.

Во многих сетях перегрузка будет проявляться как увеличение очереди пакетов, а вызванная перегрузкой потеря пакетов будет происходить только в крайних случаях. RTT также будут отображаться как более плавный сигнал, чем дискретные события потери пакетов. Это делает RTT хорошим способом идентификации отдельных абонентов, для которых сеть является узким местом в данное время или географические узлы (такие как вышки сотовой связи), которые испытывают крупномасштабную перегрузку.

Основным пределом измерения RTT как сигнала перегрузки является сложность надежного различения сегментов данных, поставленных в очередь, и ACK, поставленных в очередь.

2.3. Изменение порядка измерений

Если сеть переупорядочивает пакеты транспортных соединений, возможно, из-за неправильной конфигурации многопутевого равенства (ECMP) (например, описано в [RFC2991] и [RFC7690]), конечные точки могут реагировать так, как если бы произошла потеря пакетов, и повторно передавать пакеты или уменьшить скорость пересылки. Следовательно, сетевой оператор желает диагностировать переупорядочение пакетов.

Для TCP переупорядочение пакетов может быть обнаружено путем наблюдения порядковых номеров TCP для каждого направления. См., Например, ряд стандартных метрик переупорядочения пакетов в [RFC4737] и информационных метрик в [RFC5236].

2.4. Пропускная способность и выявление узких мест

Хотя пропускная способность по IP-адресу или от него может быть измерена без измерений транспортного уровня, транспортный уровень дает подсказки о том, что конечные точки пытались сделать.

Одним из способов быстрого исключения сети в качестве узкого места при устранении неполадок является проверка того, ограничена ли скорость конечными точками. Например, скорость соединения может вместо этого быть ограничена неоптимальными параметрами TCP, окном перегрузки отправителя, отправителем, временно исчерпывающим данные для отправки, отправителем, ожидающим отправителя, чтобы отправить другой запрос, или получателем, закрывающим окно приема.

Эти данные также полезны для промежуточных ящиков, используемых для измерения качества обслуживания сети. Соединения или части соединений, которые ограничены конечными точками, не обеспечивают точного измерения скорости сети и могут быть обесценены или полностью исключены в таких анализах.

2.5. Отзывчивость

Механизмы контроля заторов продолжают развиваться. Существуют инструменты, которые могут интерпретировать порядковые номера протоколов (например, из TCP или RTP), чтобы вывести реакцию потока на перегрузку. Такие инструменты могут использоваться операторами, чтобы помочь понять влияние определенных транспортных протоколов на другой трафик, который разделяет их сеть. Например, порядковые номера пакетов могут быть проанализированы, чтобы помочь понять, отступает ли поток приложений от своей нагрузки перед лицом постоянной перегрузки (как это делает TCP) и, следовательно, подходит ли поведение для совместного использования ограниченной пропускной способности сети.

Эти инструменты также могут быть использованы для определения необходимости механизмов в сети, чтобы препятствовать тому, чтобы потоки приобретали чрезмерную пропускную способность сети при сильной перегрузке (например, путем развертывания ограничителей скорости или сетевых транспортных автоматических выключателей [RFC8084]).

2.6. Обнаружение атаки

Когда приложение или сетевой ресурс подвергаются атаке, полезно определить эту ситуацию с точки зрения сети, расположенной выше атакованного ресурса.

Хотя методы обнаружения, как правило, являются проприетарными, обнаружение атак изнутри сети может включать:

  • выявление нехарактерных объемов или источников трафика;
  • выявление заторов, возможно, с использованием методов в разделах 2.1 и 2.2;
  • выявление незавершенных соединений или транзакций от атак, которые пытаются исчерпать ресурсы сервера;
  • Отпечатки пальцев, основанные на любых доступных полях, определены как полезные для отличия атаки от желаемого трафика.

Две тенденции в разработке протоколов усложнят обнаружение атак:

  • Желание зашифровать поля транспортного уровня;
  • Желание избежать статистической дактилоскопии путем добавления энтропии в различных формах.

При улучшении конфиденциальности такие подходы могут препятствовать обнаружению атак.

2.7. Пакетная коррупция

Одним заметным источником потери пакетов является повреждение пакетов. Это повреждение обычно не будет обнаружено до тех пор, пока контрольная сумма не будет проверена конечной точкой и пакет не будет отброшен. Это означает, что определение точного местоположения, в котором потеряны пакеты, недостаточно при устранении неполадок в сетях. Оператор хотел бы узнать, где пакеты повреждены. Проверка контрольной суммы IP и TCP позволяет измерительному устройству правильно различать повреждение пакетов в восходящем направлении и обычную потерю пакетов в нисходящем направлении.

Разработчики транспортных протоколов должны учитывать, сможет ли промежуточный ящик обнаруживать поврежденные или поврежденные пакеты.

2.8. Измерения прикладного уровня

Информация о работоспособности сети также может быть получена из диагностики на уровне приложений, например:

  • время отклика DNS и повторные передачи, рассчитанные путем сопоставления ответов на запросы;
  • Различные протоколы анализа качества голоса и видео.

Может ли этот тип информации предоставляться на транспортном уровне?

3. Функции за пределами измерения: несколько примеров

В этом разделе описываются функции, предоставляемые подключаемыми устройствами, которые выходят за пределы измерения путем изменения, отбрасывания, задержки или определения приоритетов трафика.

3.1. NAT

Трансляторы сетевых адресов (NAT) позволяют нескольким устройствам совместно использовать общий адрес, разделяя пространство портов транспортного уровня между устройствами.

Рекомендации по поведению NAT находятся для UDP в BCP 127 [RFC4787] и для TCP в BCP 142 [RFC7857].

Для поддержки NAT должны быть номера портов транспортного уровня, которые могут быть изменены NAT. Обратите внимание, что обязательные поля (например, номера портов) видны во всех транспортных протоколах, определенных IETF.

Прикладной уровень не должен предполагать, что номер порта был оставлен без изменений (например, путем включения его в контрольную сумму или его подписания).

Совместное использование адресов также используется в контексте перехода на IPv6. Например, маршрутизатор перехода семейства адресов DS-Lite (AFTR) [RFC6333], NAT64 [RFC6146] или A + P [RFC7596] [RFC7597] — это функции, которые включены в сеть, чтобы обеспечить непрерывность обслуживания IPv4 по сети IPv6.

Кроме того, из-за некоторых соображений множественной адресации преобразование префикса IPv6 может быть разрешено некоторыми предприятиями посредством преобразования префикса сетевого адреса IPv6 в IPv6 (NPTv6) [RFC6296].

3.2. Брандмауэр

Межсетевые экраны являются распространенными и важными компонентами, которые проверяют входящий и исходящий трафик. Брандмауэры, как правило, являются краеугольным камнем политики безопасности, которая применяется в помещениях конечных пользователей и других местах, чтобы обеспечить строгие гарантии в отношении трафика, который может быть авторизован для входа / выхода из указанных помещений, а также конечных пользователей, которым могут быть назначены различные уровни допуска. относительно того, к каким сетям и частям Интернета они имеют доступ.

Важным аспектом политики брандмауэра является разграничение инициируемых извне коммуникаций, инициируемых извне.

Для TCP это легко сделать, отслеживая конечный автомат TCP. Кроме того, окончание TCP-соединения обозначается флагами RST или FIN.

Для UDP брандмауэр может быть открыт, если первый пакет поступает от внутреннего пользователя, но закрытие обычно выполняется с помощью таймера простоя произвольной длительности, который может не соответствовать ожиданиям приложения.

Возможности простого брандмауэра IPv6 для абонентского оборудования (как без сохранения состояния, так и с сохранением состояния) описаны в [RFC6092].

Брандмауэр функционирует лучше, когда он может наблюдать за конечным автоматом протокола, обычно описываемым «Независимым от транспорта управлением состоянием уровня пути» [PATH-STATE].

3.3. DDoS Scrubbing

В контексте DDoS-атаки цель скруббера — отбрасывать трафик атаки, допуская при этом полезный трафик. Такой смягчитель описан в [DOTS].

Когда атаки происходят против ограниченных ресурсов, часть трафика будет отброшена, прежде чем достигнет намеченного пункта назначения. Пользователь получает лучший опыт, и сервер работает более эффективно, если скруббер может отбрасывать трафик атаки, оставляя место для законного трафика.

Очистка должна быть обеспечена сетевым устройством на пути, потому что ни одна конечная точка законного соединения не имеет никакого контроля над источником трафика атаки.

Поддельные атаки DDoS могут быть смягчены на источнике с помощью BCP 38 [RFC2827], но это более сложно, если нельзя применить фильтрацию адресов источника.

В отличие от устройств в ядре Интернета, промежуточные блоки, отслеживающие состояние двунаправленных транспортных соединений, могут отклонять трафик TCP с подделкой источника из-за неспособности предоставить разумные номера подтверждения для завершения трехстороннего рукопожатия. Очевидно, что это требует видимости промежуточной коробки в конечный автомат транспортного уровня.

Промежуточные блоки могут также очищаться на основе статистической классификации: проверки вероятности того, что данный пакет является легитимным. Поскольку разработчики протоколов добавляют больше энтропии к заголовкам и длинам, этот тест становится менее полезным, а лучшая стратегия очистки становится случайным отбрасыванием.

3.4. Неявная идентификация

Для повышения качества обслуживания конечного пользователя некоторые операторы используют функции неявной идентификации, которые полагаются на корреляцию сетевой информации для доступа к некоторым локальным услугам. Например, сервисные порталы, которыми управляют некоторые операторы, могут быть немедленно доступны конечным пользователям без какой-либо явной идентификации в целях улучшения доступности услуг. Это выполнимо благодаря подключаемым устройствам, которые вводят соответствующие метаданные, которые могут использоваться удаленным сервером для реализации политик для каждого подписчика. Информация может быть введена на прикладном уровне или на транспортном уровне (когда используется механизм совместного использования адресов).

Экспериментальная реализация с использованием опции TCP описана в [RFC7974].

Для предполагаемого использования неявной идентификации более безопасно, чтобы доверенный промежуточный ящик отмечал этот трафик, чем доверять устройствам конечного пользователя.

3.5. Улучшающие производительность прокси

Улучшающие производительность прокси-серверы (PEP) могут повысить производительность в некоторых типах сетей за счет улучшения разнесения пакетов или генерирования локальных подтверждений; они чаще всего используются в спутниковых и сотовых сетях. PEP транспортного уровня описаны в разделе 2.1.1 [RFC3135].

PEP позволяют централизованно развертывать алгоритмы управления перегрузкой, более подходящие для конкретной сети, чаще всего для управления перегрузкой на основе задержки. Более продвинутые протоколы TCP PEP развертывают системы контроля перегрузки, которые рассматривают все TCP-соединения одного конечного пользователя как единое целое, улучшая справедливость и позволяя быстрее реагировать на изменения состояния сети. Например, сообщалось, что разделение TCP-соединений в некоторых сетевых доступах может привести к сокращению времени загрузки страницы в два раза [ICCRG].

Локальные подтверждения, генерируемые PEP, ускоряют медленный запуск TCP, разделяя эффективную задержку, и они позволяют выполнять повторную передачу из PEP, а не из фактического отправителя. Локальные подтверждения также позволят PEP поддерживать локальный буфер данных, соответствующий фактическим условиям сети, тогда как фактические конечные точки часто отправляют слишком много или слишком мало.

Функция PEP требует наличия полей транспортного уровня, которые позволяют идентифицировать порции данных (например, порядковые номера TCP), идентифицировать подтверждения (например, номера ACK TCP) и создавать подтверждения из PEP.

Обратите внимание, что PEP полезны только в некоторых типах сетей. В частности, PEP очень полезны в тех случаях, когда стратегии управления перегрузкой конечных точек не подходят для сети, соединяющей их. При этом плохой дизайн может привести к ухудшению производительности при развертывании PEP.

3.6. Сетевое кодирование

Сетевое кодирование — это метод повышения производительности передачи по линиям связи с низкой пропускной способностью и длинной задержкой, таким как некоторые спутниковые линии. Кодирование может включать сжатие без потерь и / или добавление избыточности в заголовки и полезную нагрузку. Таксономия сетевого кодирования предоставляется в [RFC8406]; Примером сквозного кодирования является FECFRAME [RFC6363]. Как правило, он развертывается со шлюзами сетевого кодирования на каждом конце этих каналов, с туннелем сетевого кодирования между ними по каналам с медленной / с потерями / длинной задержкой.

Реализации сетевого кодирования могут быть специфичны для TCP, используя преимущества известных свойств протокола.

Шлюзы сетевого кодирования могут использовать некоторые методы PEP, такие как создание подтверждений данных в очереди, удаление повторных передач и скорость передачи данных в темпе, чтобы уменьшить колебание очереди.

Интерес к большему количеству сетевого кодирования в некоторых конкретных сетях обсуждается в [SATELLITES].

Примечание. Это не следует путать с транскодированием, которое выполняет сжатие с потерями в передаваемых медиапотоках и не входит в сферу применения этого документа.

3.7. Агрегирование полосы пропускания с помощью сети

Точка агрегации гибридного доступа — это промежуточное звено, которое позволяет клиентам объединять пропускную способность технологий множественного доступа.

Один из подходов использует многопутевые TCP (MPTCP) прокси [TCP-CONVERT] для пересылки трафика по нескольким путям. Прокси MPTCP работает на транспортном уровне, находясь в сети оператора.

Поддержка многопутевых транспортных возможностей посредством связи хостов остается привилегированной целевой схемой, так что такие хосты могут напрямую использовать доступные ресурсы, предоставляемые различными сетями доступа, к которым они могут подключаться. Тем не менее, сетевые операторы не контролируют конечные хосты, тогда как поддержка MPTCP контент-серверами остается незначительной.

Модели развертывания MPTCP с поддержкой сети предназначены для облегчения принятия MPTCP для установления многолучевого обмена данными без каких-либо предположений о поддержке возможностей MPTCP посредством обмена данными между партнерами. Модели развертывания MPTCP с поддержкой сети полагаются на точки преобразования MPTCP (MCP), которые действуют от имени хостов, чтобы они могли использовать преимущества установления связи по нескольким путям [TCP-CONVERT].

Обратите внимание, что существуют случаи, когда сквозной MPTCP нельзя использовать, даже если клиент и сервер совместимы с MPTCP. В этих случаях прокси MPTCP может обеспечить использование многолучевого распространения. Примеры таких случаев перечислены ниже:

  1. Использование частных IPv4-адресов в некоторых сетях доступа. Как правило, дополнительные подпотоки не могут быть добавлены к соединению MPTCP без помощи MCP.
  2. Назначение префиксов IPv6 только в некоторых сетях. Если сервер только для IPv4, подпотоки IPv6 не могут быть добавлены к соединению MPTCP, установленному с этим сервером, по определению.
  3. Подписка на некоторые предложения услуг зависит от объема квоты.

3.8. Расстановка приоритетов и дифференцированные услуги

Объемный трафик может обслуживаться с большей задержкой, чем интерактивный трафик, без снижения пропускной способности. Этот факт позволяет функции промежуточного ящика улучшить время отклика в интерактивных приложениях, устанавливая приоритеты, контролируя или отмечая интерактивные транспортные соединения в отличие от транспортных соединений с массовым трафиком. Например, игровой трафик может иметь приоритет над электронной почтой или обновлениями программного обеспечения. Рекомендации по настройке для классов обслуживания Diffserv обсуждаются в [RFC4594].

Промежуточные блоки могут идентифицировать различные классы трафика путем проверки нескольких уровней заголовка и длины полезной нагрузки.

3.9. Формирование на основе измерений

Базовая функциональность формирования трафика не требует информации транспортного уровня. Все, что нужно, — это способ сопоставления каждого пакета с квотой формирователя трафика. Например, может существовать ограничение скорости на 5 кортежей или на IP-адрес абонента. Однако такие фиксированные правила формирования трафика бесполезны, поскольку в конечном итоге они ограничивают скорость трафика, даже когда в сети имеются свободные ресурсы.

Более продвинутые устройства формирования трафика используют метрики транспортного уровня, описанные в разделе 2, для обнаружения перегрузки на уровне сайта или пользователя и используют различные правила формирования трафика при обнаружении перегрузки [RFC3272]. Устройство такого типа может преодолевать ограничения нисходящих устройств, которые ведут себя плохо (например, из-за чрезмерной буферизации или субоптимального отбрасывания пакетов).

3.10. Справедливость по отношению к квоте конечного пользователя

Некоторые предложения услуг основаны на модели тарификации на основе объема (например, тарифные планы на основе объема, предлагаемые сотовыми провайдерами). Операторы могут помогать конечным пользователям в сохранении их квоты данных путем развертывания функций на маршруте, которые формируют трафик, который в противном случае был бы агрессивно передан.

Например, быстрая загрузка видео, которое не будет полностью просматриваться подписчиком, может привести к быстрому исчерпанию квоты данных. Ограничение скорости загрузки видео сохраняет квоту в пользу конечного пользователя. Кроме того, отбрасывание нежелательного входящего трафика предотвращает несправедливое исчерпание квоты пользователя.

4. Соображения IANA

В этом документе нет действий IANA.

5. Вопросы безопасности

5.1. Конфиденциальность и конфиденциальность

Этот документ преднамеренно исключает промежуточные блоки, которые наблюдают или манипулируют данными прикладного уровня.

Измерения и функции, описанные в этом документе, могут быть реализованы без нарушения конфиденциальности [RFC6973]. Однако всегда возникает вопрос о том, могут ли поля и свойства пакета, используемые для достижения эксплуатационных выгод, также использоваться для нанесения вреда.

В частности, вопрос заключается в том, какая конфиденциальность теряется при раскрытии полей транспортного уровня, помимо того, что можно узнать, наблюдая за полями IP-уровня:

  • Порядковые номера: наблюдатель может узнать, сколько данных передано.
  • Индикаторы Start / Stop: наблюдатель может подсчитывать транзакции для некоторых приложений.
  • Отпечатки пальцев устройства: наблюдателю может быть легче определить тип устройства, когда разные устройства используют разные значения или параметры поля по умолчанию.

5.2. Активные атаки на пути

Злоумышленник на пути, способный наблюдать порядковые номера или идентификаторы сеанса, может облегчить изменение или разрыв транспортного соединения. Например, наблюдение за порядковыми номерами TCP позволяет генерировать пакет RST, который завершает соединение. Однако подписывание транспортных полей смягчает эту атаку. Атака и решение описаны для опции аутентификации TCP [RFC5925]. Тем не менее, злоумышленник, находящийся на пути, также может отбросить поток трафика.

5.3. Улучшенная безопасность

Обслуживаемость и безопасность сети могут быть улучшены путем предоставления брандмауэрам и механизмам DDoS некоторой информации о транспортных соединениях. Напротив, было бы очень трудно защитить сеть, в которой каждый пакет выглядит уникальным и заполненным случайными битами (с точки зрения устройства на тракте).

Таким образом, некоторые функции, обеспечивающие возможность смягчать / фильтровать атаки благодаря сетевому механизму, повышают безопасность, например, посредством открытой сигнализации об угрозе отказа в обслуживании (DOTS) [DOTS-SIGNAL].

6. Информационные ссылки

[DOTS] Mortensen, A., Andreasen, F., Reddy, T., Compton, R., and N. Teague, «Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture», Work in Progress, draft-ietf-dots-architecture-07, September 2018.

[DOTS-SIGNAL] Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification», Work in Progress, draft-ietf-dots-signal-channel-25, September 2018.

[ICCRG] Kuhn, N., «MPTCP and BBR performance over Internet satellite paths», IETF 100, 2017, <https://datatracker.ietf.org/meeting/100/materials/slides-100-iccrg-mptcp-and-bbr-performance-over-satcomlinks-00>.

[PATH-STATE] Kuehlewind, M., Trammell, B., and J. Hildebrand, «Transport-Independent Path Layer State Management», Work in Progress, draft-trammell-plus-statefulness-04, November 2017.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[RFC2827] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.

[RFC2991] Thaler, D. and C. Hopps, «Multipath Issues in Unicast and Multicast Next-Hop Selection», RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.

[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, «Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations», RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3234] Carpenter, B. and S. Brim, «Middleboxes: Taxonomy and Issues», RFC 3234, DOI 10.17487/RFC3234, February 2002, <https://www.rfc-editor.org/info/rfc3234>.

[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, «Overview and Principles of Internet Traffic Engineering», RFC 3272, DOI 10.17487/RFC3272, May 2002,
<https://www.rfc-editor.org/info/rfc3272>.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, «Configuration Guidelines for DiffServ Service Classes», RFC 4594, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, «Packet Reordering Metrics», RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.

[RFC4787] Audet, F., Ed. and C. Jennings, «Network Address Translation (NAT) Behavioral Requirements for Unicast UDP», BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.

[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. Whitner, «Improved Packet Reordering Metrics», RFC 5236, DOI 10.17487/RFC5236, June 2008, <https://www.rfc-editor.org/info/rfc5236>.

[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, «Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC)
Deployments», RFC 5853, DOI 10.17487/RFC5853, April 2010, <https://www.rfc-editor.org/info/rfc5853>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, «The TCP Authentication Option», RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6092] Woodyatt, J., Ed., «Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service», RFC 6092,
DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, «Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers», RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, «Issues with IP Address Sharing», RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.

[RFC6296] Wasserman, M. and F. Baker, «IPv6-to-IPv6 Network Prefix Translation», RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, «Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion», RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>.

[RFC6363] Watson, M., Begen, A., and V. Roca, «Forward Error Correction (FEC) Framework», RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.

[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, «IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)»,
RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, «Privacy Considerations for Internet Protocols», RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., «TCP Extensions for High Performance», RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., «Problem Statement for Service Function Chaining», RFC 7498, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>.

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, «Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture», RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>.

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., «Mapping of Address and Port with Encapsulation (MAP-E)», RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.

[RFC7690] Byerly, M., Hite, M., and J. Jaeggli, «Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))», RFC 7690, DOI 10.17487/RFC7690, January 2016, <https://www.rfc-editor.org/info/rfc7690>.

[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, «Updates to Network Address Translation (NAT) Behavioral Requirements», BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.

[RFC7974] Williams, B., Boucadair, M., and D. Wing, «An Experimental TCP Option for Host Identification», RFC 7974, DOI 10.17487/RFC7974, October 2016, <https://www.rfc-editor.org/info/rfc7974>.

[RFC8084] Fairhurst, G., «Network Transport Circuit Breakers», BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.

[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., «Effects of Pervasive Encryption on Operators», RFC 8404, DOI 10.17487/RFC8404, July 2018,
<https://www.rfc-editor.org/info/rfc8404>.

[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
S. Sivakumar, «Taxonomy of Coding Techniques for Efficient Network Communications», RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.

[SATELLITES] Kuhn, N. and E. Lochin, «Network coding and satellites», Work in Progress, draft-irtf-nwcrg-network-codingsatellites-02, November 2018.

[TCP-CONVERT] Bonaventure, O., Boucadair, M., Gundavelli, S., and S. Seo, «0-RTT TCP Convert Protocol», Work in Progress, draft-ietf-tcpm-converters-04, October 2018.

[USE-CASE] Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, «Service Function Chaining Use Cases in Mobile Networks», Work in Progress, draft-ietf-sfc-use-case-mobility-08,
May 2018.

Благодарности

Авторы выражают благодарность Брайану Траммеллу, Брайану Карпентеру, Мирье Куелевинду, Кэтлин Мориарти, Горри Фэрхерсту, Адриану Фаррелу и Николя Куну за их обзор и предложения.

Адреса авторов

David Dolson (editor)
Email: ddolson@acm.org

Juho Snellman
Email: jsnell@iki.fi

Mohamed Boucadair (editor)
Orange
4 rue du Clos Courtel
Rennes 35000
France
Email: mohamed.boucadair@orange.com

Christian Jacquenet
Orange
4 rue du Clos Courtel
Rennes 35000
France
Email: christian.jacquenet@orange.com

Поделись записью