Network Working Group L-A. Larzon Request for Comments: 3828 Lulea University of Technology Category: Standards Track M. Degermark S. Pink The University of Arizona L-E. Jonsson, Ed. Ericsson G. Fairhurst, Ed. University of Aberdeen July 2004
Облегченный протокол пользовательских дейтаграмм (UDP-Lite)
The Lightweight User Datagram Protocol (UDP-Lite)
Статус документа
Данный документ содержит стандарт протокола Internet, предложенного сообществу Internet, и является приглашением к дискуссии в целях развития этого протокола. Сведения о текущем состоянии стандартизации протокола вы найдете в документе Internet Official Protocol Standards (STD 1). Документ можно распространять без ограничений.
Авторские права
Copyright (C) The Internet Society (2004).
Аннотация
Данный документ описывает протокол UDP-Lite1, подобный протоколу UDP2 (RFC 768), но может также обслуживать в склонных к ошибкам сетевых средах приложения, которые предпочитают получать частично подтвержденные дейтаграммы, но не отбрасывать пакеты при любой ошибке. Если это свойство не использовать, UDP-Lite семантически идентичен протоколу UDP.
1. Введение
Этот документ описывает новый транспортный протокол UDP-Lite, известный также, как UDPLite. Основой нового протокола служат три наблюдения:
Во первых, существует класс приложений, которые получат преимущества, если поврежденные данные будут доставляться, а не отбрасываться. Множество кодеков для голоcа и видео относятся к этому классу (например, кодек речи AMR [RFC 3267], кодек Internet Low Bit Rate Codec [ILBRC], устойчивые к ошибкам видеокодеки H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], MPEG-4 [ISO-14496]). Эти кодеки могут разрабатываться так, что ошибки в данных для них будут предпочтительней отбрасывания пакетов целиком.
Во вторых, всем каналам, поддерживающим передачу трафика IP, следует использовать строгую проверку целостности на канальном уровне (например, CRC-32 [RFC 3819]) и эта проверка должна по умолчанию использоваться для трафика IP. Когда нижележащий канальный уровень поддерживает такую проверку, некоторые типы трафика (например, UDP-Lite) могут получить преимущества в результате смены поведения канального уровня, позволяющей по запросу пересылку частично поврежденных пакетов IP [RFC 3819]. Некоторые радио-технологии (например, [3GPP]) поддерживают такое поведение при работе при работе в точках, где стоимость и задержки достаточно малы. Если склонные к ошибкам каналы знают о чувствительной к ошибкам части пакета, для физического соединения можно обеспечить дополнительную защиту за счет снижения вероятности повреждения чувствительных к ошибкам байтов (например, использовать неоднородную упреждающую коррекцию ошибок FEC3).
В третьих, промежуточным уровням (т. е., IP и протокол транспортного уровня) не следует запрещать работу устойчивых к ошибкам приложений при наличии таких каналов. Протокол IP не создает проблем в этом отношении, поскольку заголовок IP включает контрольную сумму, покрывающую все данные пакета IP. Из транспортных протоколов общего назначения лучше всего подходит UDP, поскольку он не создает издержек, связанных с повтором передачи ошибочных пакетов, нарушением порядка доставки и коррекцией ошибок. Для IPv4 [RFC 791] контрольная сумма UDP покрывает пакет целиком или просто не используется. Для IPv6 [RFC 2460] контрольная сумма UDP является обязательной и ее использование не может быть отключено. Заголовок IPv6 не включает контрольной суммы самого заголовка и считается необходимым всегда защищать адресную информацию IP с помощью обязательной контрольной суммы UDP.
Требуется транспортный протокол, который соответствует свойствам канального уровня и перечисленным выше требованиям [LDP99]. Механизм детектирования ошибок транспортного уровня должен обеспечивать защиту важной информации (такой, как заголовки) вкупе с игнорированием ошибок, с которыми лучше иметь дело приложениям. Набор октетов, проверяемых с помощью контрольной суммы, лучше всего задавать со стороны передающего приложения.
Протокол UDP-Lite обеспечивает поддержку контрольных сумм с необязательным частичным покрытием. При использовании этой опции пакет делится на две части – чувствительную к ошибкам (покрывается контрольной суммой) и нечувствительную к ним (не покрывается контрольной суммой). Ошибки в нечувствительной к ним части не будут приводить к отбрасыванию пакетов транспортным уровнем принимающего конечного хоста. Когда контрольная сумма покрывает весь пакет (это следует делать по умолчанию), UDP-Lite семантически идентичен протоколу UDP.
По сравнению с UDP, неполные контрольные суммы UDP-Lite обеспечивают дополнительную гибкость для приложений, которые хотят определить часть своих данных в пакетах, как нечувствительную к ошибкам.
2. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC-2119].
3. Описание протокола
Заголовок пакетов UDP-Lite показан на рисунке 1. Его формат отличается от формата UDP – поле Length заменено полем Checksum Coverage. Эта замена допустима, поскольку информация о размере пакета UDP может быть обеспечена модулем IP так же, как это делается для TCP [RFC 793].
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Рисунок 1: Формат заголовка UDP-Lite
3.1. Поля
Поля Source Port и Destination Port определяются, как в спецификации UDP [RFC 768]. Протокол UDP-Lite использует тот же набор портов, который выделен агентством IANA для использования с UDP.
Поле Checksum Coverage указывает число октетов, начиная с первого октета заголовка UDP-Lite, используемых для расчета контрольной суммы. Заголовок UDP-Lite должен всегда покрываться контрольной суммой. Вопреки этому требованию значение Checksum Coverage выражается числом октетов от начала заголовка UDP-Lite, как это делается для UDP. Нулевое значение Checksum Coverage показывает, что контрольная сумма вычисляется для всего пакета UDP-Lite. Это означает, что отличные от 0 значения поля Checksum Coverage должны быть не меньше 84. Пакеты UDP-Lite со значением поля Checksum Coverage от 1 до 7 должны отбрасываться получателем. Безотносительно к значению Checksum Coverage поле Checksum должно учитывать псевдозаголовок, основанный на заголовке IP (см. ниже). Пакеты UDP-Lite со значением поля Checksum Coverage, превышающим размер IP, также должны отбрасываться.
Поле Checksum содержит 16-битовое поразрядное дополнение до 1 суммы поразрядных дополнений до 1 для информации псевдозаголовка, собранной из заголовка IP, числа октетов, заданного полем Checksum Coverage (начиная с первого октета в заголовке UDP-Lite), возможно дополненного октетом нулей в конце для выравнивания по 16-битовой границе [RFC 1071]. Перед расчетом контрольной суммы значение поля Checksum принимается нулевым. Если рассчитанная контрольная сумма равна 0, она передается как «все единицы» (эквивалентны в арифметике с дополнением до 1).
Поскольку недопустима передача контрольной суммы, состоящей только из нулей, приложениям UDP-Lite, не желающим защищать свои данные с помощью контрольной суммы, следует использовать Checksum Coverage = 8. Это отличается от использования протокола UDP на основе IPv4 тем, что минимальная контрольная сумма UDP-Lite всегда покрывает заголовок UDP-Lite, который включает поле Checksum Coverage.
3.2. Псевдозаголовок
Протоколы UDP и UDP-Lite используют однотипный псевдозаголовок с уровня IP для расчета контрольной суммы. Этот псевдозаголовок различается для протоколов IPv4 и IPv6. Псевдозаголовок UDP-Lite отличается от псевдозаголовка UDP тем, что поле Length берется не из заголовка UDP-Lite, а из информации, предоставляемой модулем IP. Расчет производится так же, как для протокола TCP [RFC 793], и предполагает, что поле Length псевдозаголовка включает заголовок UDP-Lite и все последующие октеты данных IP.
3.3. Интерфейс с приложением
Интерфейсу с прикладным уровнем следует разрешать такие же операции, как для протокола UDP. Кроме того, для передающего приложения следует обеспечивать способ передачи значения Checksum Coverage модулю UDP-Lite. Следует также обеспечивать способ передачи значения Checksum Coverage принимающему приложению или, по крайней мере, позволить принимающему приложению блокировать доставку пакетов, в которых покрытие для контрольной суммы меньше, чем значение, представленное этим приложением.
Рекомендуется по умолчанию протоколу UDP-Lite вести себя, подобно UDP, устанавливая значение поля Checksum Coverage соответствующим размеру пакета UDP-Lite и проверяя весь пакет. Приложениям, желающим определить часть своих данных, как нечувствительные к битовым ошибкам (например, для устойчивых к ошибкам кодеков RTP [RFC 3550]), следует делать это путем явного системного вызова на стороне отправителя. Приложениям, желающим получать данные с неполным покрытием для контрольной суммы, следует информировать принимающую систему с помощью явного системного вызова.
Характеристики каналов, формирующих путь через Internet, могут существенно различаться. Следовательно, трудно делать какие-либо предположения об уровне или характере ошибок, которые могут приводить к повреждению нечувствительной части данных пакетов UDP-Lite. Приложениям, использующим UDP-Lite, не следует делать каких-либо предположений о корректности принятых данных за пределами области, указанной полем Checksum Coverage, и следует, при необходимости пользоваться своими средствами контроля ошибок.
3.4. Интерфейс с IP
Как для UDP, модуль IP должен обеспечивать псевдозаголовок модулю протокола UDP-Lite (его называют также модулем UDPLite). Псевдозаголовок UDP-Lite содержит поля адресов IP и поле протокола из заголовка IP, а также размер данных IP, который определяется на основе поля Length в заголовке IP.
Передающему модулю IP недопустимо дополнять данные IP октетами заполнения, поскольку размер данных UDP-Lite, доставляемых принимающему приложению, определяется размером данных IP.
3.5. Джамбограммы
Поле Checksum Coverage имеет размер 16 битов и может представлять значения Checksum Coverage вплоть до 65535 октетов. Это позволяет использовать любое покрытие для контрольной суммы пакетов IP, если они не относятся к числу Jumbogram. Для Jumbogram контрольная сумма будет покрывать все данные (Checksum Coverage = 0) или не более 65535 начальных октетов пакета UDP-Lite.
4. Нижележащий уровень
Поскольку UDP-Lite может доставлять пакеты с поврежденными данными приложениям, которые пожелали такие пакеты получать, кадры, содержащие пакеты UDP-Lite, не требуется отбрасывать на нижележащих уровнях при обнаружении ошибок в нечувствительной части. Для каналов, поддерживающих частичное детектирование ошибок, поле Checksum Coverage в заголовке UDP-Lite может использоваться в качестве рекомендации где не следует проверять наличие ошибок. Нижележащие уровни должны использовать строгий механизм детектирования ошибок [RFC 3819] для обнаружения по крайней мере ошибок в чувствительной части и отбрасывания поврежденных пакетов. Чувствительная часть включает октеты, начиная с первого октета заголовка IP и заканчивая последним октетом, указанным полем Checksum Coverage. Чувствительная часть будет, таким образом, трактоваться в точности так же, как для пакета UDP.
Канальные уровни, не поддерживающие частичного детектирования ошибок, подходящего для UDP-Lite, как описано выше, должны детектировать ошибки во всем пакете UDP-Lite и отбрасывать поврежденные пакеты [RFC 3819]. Весь пакет UDP-Lite в этом случае трактуется в точности как пакет UDP.
Следует отметить, что протокол UDP-Lite будет отличаться для приложений только в том случае, когда частичное детектирование ошибок, основанное на неполных контрольных суммах UDP-Lite, реализовано также на канальном уровне, как сказано выше. Использование частичного детектирования ошибок на канальном уровне будет давать эффект только при работе через склонные к ошибкам каналы.
5. Совместимость с UDP
Протоколы UDP и UDP-Lite похожи синтаксически и семантически. Приложения, разработанные для UDP могут, следовательно, использовать взамен протокол UDP-Lite и по умолчанию будут получать полное покрытие для контрольной суммы. Сходство протоколов также упрощает реализацию UDP-Lite, поскольку требуется внести сравнительно небольшие изменения в существующие реализации UDP.
Протоколу UDP-Lite был выделен отдельный идентификатор протокола IP – 136 (UDPLite), что позволяет получателю отличить протокол UDP от протокола UDP-Lite. Конечный хост-адресат, не поддерживающий UDP-Lite, будет в общем случае возвращать сообщение ICMP Protocol Unreachable или ICMPv6 Payload Type Unknown (в зависимости от типа протокола IP). Этот простой метод детектирования не поддерживающих UDP-Lite систем является главным преимуществом использования отдельного идентификатора протокола.
В оставшейся части этой главы дается обоснование выделению отдельного идентификатора протокола IP для UDP-Lite, вместо использования имеющегося идентификатора для UDP.
Не существует известных проблем взаимодействия между UDP и UDP-Lite при использовании обоими протоколами одного идентификатора IP. В частности, не возникает ситуаций, когда пакет, способный вызвать проблемы, будет доставлен не подозревающему об этом приложению – данные UDP-Lite с частичным покрытием для контрольной суммы не могут быть доставлены приложениям UDP, а пакеты UDP, не полностью заполняющие поле данных IP, не могут быть доставлены приложениям, использующим UDP-Lite.
Однако при использовании протоколами UDP и UDP-Lite одного идентификатора, если реализация UDP-Lite будет передавать пакеты UDP-Lite с неполным покрытием для контрольной суммы реализации UDP, последняя будет отбрасывать пакеты без уведомления, поскольку несоответствие псевдозаголовков приведет к отказу при проверке контрольной суммы UDP. Ни одно из приложений не получит уведомления о сложившейся ситуации. Решениями этой проблемы могут служить:
- явная сигнализация на прикладном уровне через основное соединение (пока не используется опция частичного покрытия для контрольной суммы), позволяющая отправителю узнать, поддерживает ли получатель протокол UDP-Lite;
- использование отдельной сигнализации (например, H.323, SIP или RTCP) для передачи информации о поддержке получателем протокола UDP-Lite.
Поскольку протоколу UDP-Lite присвоен свой идентификатор протокола IP, не возникает необходимости рассмотрения возможности доставки пакета UDP-Lite в ничего не подозревающий порт UDP.
6. Вопросы безопасности
Вопросы безопасности UDP-Lite связаны с взаимодействием данного протокола с механизмами аутентификации и шифрования. При использовании опции неполного покрытия для контрольных сумм UDP-Lite нечувствительная к ошибкам часть пакета может быть изменена в процессе доставки. Это вступает в противоречие с идеей, лежащей в основе большинства механизмов аутентификации – аутентификация считается успешной, если пакет не изменен в процессе передачи. Пока не будет разработан и развернут механизм аутентификации, способный работать только с чувствительной частью пакета, аутентификация всегда будет приводить к отказу для пакетов UDP-Lite с повреждениями в нечувствительной к ошибкам части.
Проверка целостности IPsec (Encapsulation Security Protocol, ESP [RFC 2406] или Authentication Header, AH [RFC 2402]) применяется (как минимум) ко всей области данных пакета IP. Повреждение любого бита в защищенной области будет приводить к тому, что уровень IP на приемной стороне будет отбрасывать все поврежденные пакеты UDP-Lite.
При использовании IPsec с ESP для шифрования данных канал не может идентифицировать транспортный протокол пересылаемых пакетов путем просмотра области данных IP. В таких случаях канал должен обеспечивать стандартную проверку целостности для всего пакета IP. В этом случае протокол UDP-Lite не дает никаких преимуществ.
Для передачи данных может использоваться шифрование (например, на прикладном или транспортном уровне). В этом случае при повреждении небольшого числа битов пакета механизм дешифровки обычно приводит к распространению ошибки и пакет становится непригодным для использования. Подобное поведение характерно для многих современных механизмов шифрования. Существуют потоковые шифры, которые не приводят к распространению ошибок при дешифровке. Отметим, что отказ от проверки целостности может при некоторых обстоятельствах создавать риск потери конфиденциальности [Bellovin98]. Точность потоковых шифров обусловлена использованием собственных challenge [BB01]. В частности, атакующий может внести предсказуемые изменения в зашифрованный текст даже без его расшифровки.
7. Согласование с IANA
Новый номер протокола IP (1360 был выделен для протокола UDP-Lite. С этим идентификатором связано также имя UDPLite. Такое имя обеспечивает совместимость с широким спектром платформ, поскольку на некоторых платформах символ «-» не может быть частью имени протокольного объекта.
8. Литература
8.1. Нормативные документы
[RFC-768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, August 1980.
[RFC-791] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.
[RFC-793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, September 1981.
[RFC-1071] Braden, R., Borman, D. and C. Partridge, “Computing the Internet Checksum”, RFC 1071, September 1988.
[RFC-2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC-2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.
8.2. Дополнительная литература
[Bellovin98] Bellovin, S.M., “Cryptography and the Internet”, in Proceedings of CRYPTO ’98, August 1988.
[BB01] Bellovin, S. and M. Blaze, “Cryptographic Modes of Operation for the Internet”, Second NIST Workshop on Modes of Operation, August 2001.
[3GPP] “Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture”, TS 23.107 V5.9.0, Technical Specification 3rd Generation Partnership Project, June 2003.
[H.264] Hannuksela, M.M., Stockhammer, T., Westerlund, M. and D. Singer, “RTP payload Format for H.264 Video”, Internet Draft, Work in Progress6, March 2003.
[ILBRC] S.V. Andersen, et. al., “Internet Low Bit Rate Codec”, Work in Progress7, March 2003.
[ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), “Information Technology Coding of Audio-Visual Objects”, January 2000.
[ITU-H.263] “Video Coding for Low Bit Rate Communication,” ITU-T Recommendation H.263, January 1998.
[ITU-H.264] “Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification”, ITU-T Recommendation H.264, May 2003.
[RFC-3819] Karn, Ed., P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. And L. Wood, “Advice for Internet Subnetwork Designers”, BCP 89, RFC 3819, July 2004.
[RFC-3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, RFC 3550, July 2003.
[RFC-2402] Kent, S. and R. Atkinson, “IP Authentication Header”, RFC 24028, November 1998.
[RFC-2406] Kent, S. and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, RFC 24069, November 1998.
[RFC-3267] Sjoberg, J., Westerlund, M., Lakeaniemi, A. and Q. Xie, “Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs”, RFC 3267, June 2002.
[LDP99] Larzon, L-A., Degermark, M. and S. Pink, “UDP Lite for Real-Time Multimedia Applications”, Proceedings of the IEEE International Conference of Communications (ICC), 1999.
9. Благодарности
Спасибо Ghyslain Pelletier за важные технические и редакторские комментарии. Благодарим также Steven Bellovin, Elisabetta Carrara и Mats Naslund за обзор главы, посвященной безопасности, и Peter Eriksson за просмотр документа с точки зрения языка, значительно улучшивший понимание документа.
10. Адреса авторов
Lars-Ake Larzon
Department of CS & EE
Lulea University of Technology
S-971 87 Lulea, Sweden
EMail: lln@csee.ltu.se
Mikael Degermark
Department of Computer Science
The University of Arizona
P.O. Box 210077
Tucson, AZ 85721-0077, USA
EMail: micke@cs.arizona.edu
Stephen Pink
The University of Arizona
P.O. Box 210077
Tucson, AZ 85721-0077, USA
EMail: steve@cs.arizona.edu
Lars-Erik Jonsson
Ericsson AB
Box 920
S-971 28 Lulea, Sweden
EMail: lars-erik.jonsson@ericsson.com
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE, UK
EMail: gorry@erg.abdn.ac.uk
Перевод на русский язык
Николай Малых
11. Полное заявление авторских прав
Copyright (C) The Internet Society (2004).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечивается Internet Society.
1Lightweight User Datagram Protocol – облегченный протокол пользовательских дейтаграмм.
2User Datagram Protocol – протокол пользовательских дейтаграмм.
3Forward Error Correction.
4Размер заголовка UDP-Lite. Прим. перев.
5Перевод этого документа доступен на сайте www.protokols.ru. Прим. перев.
6Работа завершена и опубликована в RFC 3984. Прим. перев.
7Работа завершена и опубликована в RFC 3951. Прим. перев.
