Тип адреса: TLV

Данное поле содержит параметр типа адреса IPv4 Или IPv6. Данный параметр занимает TLV полностью. Он информирует принимающую сторону о том, что из существующего соединения должен быть удален определенный адрес.

Пример TLV, удаляющего адрес IPv4 10.1.1.1 из существующего соединения, может выглядеть следующим образом:

4.11.3. Новые причины ошибок

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

Запрос удаления последнего адреса IP: сторона, принявшая сообщение об этой ошибке, передавала запрос об удалении последнего адреса IP из своего соединения с равноуровневым объектом. Данная причина ошибки указывает, что запрос был отклонен.

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

4.11.4. Процедуры

В данном пункте определены процедуры для передачи порции достоверной информации и параметра REL- REQ добавления/удаления адреса IP. Дальнейшие расширения, которые будут применять передачу порции достоверной информации, не должны изменять процедуры передачи самой порции информации. Расширения должны детализировать только процедуры, относящиеся к определяемым ими параметрам REL-REQ.

4.11.4.1. Процедуры, относящиеся к порции достоверной информации

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

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

А2. Порции информации должен быть присвоен порядковый номер. Он должен назначаться по возрастанию. Все порядковые номера для инициализации на этапе установления соединения определены теми же значениями, что и начальные порядковые номера транзакции (Initial TSN).

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

А4. Запускается таймер Т-4 RTO с использованием значения RTO выбранного адреса пункта назначения.

А5. Когда поступает сообщение REL-ACK, подтверждающее последний переданный порядковый номер, останавливается таймер Т-4 RTO, разъединяется соответствующее соединение и выключаются счетчики ошибок информации пункта назначения.

Если таймер Т-4 RTO истекает, оконечный пункт должен выполнить следующие действия:

81. Нарастить показания счетчика ошибок и выполнить процедуру обнаружения неисправности тракта на соответствующем адресе пункта назначения.

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

83. Повторно передать последнюю отправленную порцию информации REL-REQ и, если возможно, выбрать альтернативный адрес пункта назначения. Оконечный пункт не должен добавлять новые параметры к данной порции информации, они должны оставаться теми же (включая порядковый номер), что и последние переданные в REL-REQ.

84. Произвести рестарт таймера Т-4 RTO.

Примечание. Общее количество повторных передач ограничивается установками счетчика. Если достигнуто максимальное значение, соединение даст сбой и перейдет в состояние CLOSED.

4.11.4.2. Управление перегрузками порций достоверной информации

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

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

R2. Информация REL-REQ не должна передаваться, если в действующем в настоящее время окне перегрузки отсутствует место.

R3. Порция информации REL-REQ должна нести только ту информацию, которая будет использована равноуровневым оконечным пунктом SCTP.

R4. Информация REL-REQ может быть ассоциирована с любым типом порций информации, кроме REL-REQ.

R5. Информация REL-ACK может быть связана с любым типом порций информации, кроме REL-ACK.

4.11.4.3. Действия после приема порции информации REL-REQ

Когда оконечный пункт получает порцию информации REL-REQ от удаленного равноуровневого объекта, он должен выполнить следующие действия:

С1. Сравнить значение порядкового номера с переменным значением порядкового номера равноуровневого объекта Peer-Serial-Number нового соединения, сохраненным оконечным пунктом. Это значение должно быть равно первоначальному значению TSN минус 1.

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

VI. Обработать TLV, содержащиеся в порции информации, выполняя соответствующие действия по инструкции.

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

V3. После обработки порции информации в целом оконечный пункт должен передать сообщение об операционных ошибках в связке с порцией информации REL-ACK, подтверждающей прием и обработку порции информации REL-REQ.

V4. Обновить порядковый номер равноуровневого объекта Реег-Serial-Number в соответствии со значением, обнаруженным в поле порядкового номера.

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

XI. Проанализировать TLV порции информации REL-REQ, но не предпринимать никаких действий в отношении анализируемых TLV (данные действия уже выполнялись ранее).

Х2. Создать сообщение ответа с указанием соответствующих операционных ошибок для любого непонятого параметра, как определено в битах типа параметра REL-REQ.

ХЗ. После проведения анализа порции информации в целом оконечный пункт должен передать информацию об операционных ошибках в связке с порцией информации REL-ACK, подтверждающей прием и обработку порции информации REL-REQ.

Х4. Оконечный пункт не должен обновлять порядковый номер равноуровневого объекта .

С4. В обоих случаях C2:V3 и СЗ:ХЗ сообщение REL-ACK должно быть передано в обратном направлении в адрес источника, содержащийся в заголовке IP информации REL-REQ, на которую требуется отзыв.

4.11.4.4. Добавление и удаление адреса IP

При построении параметров TLV для сообщений порций информации REL-REQ, предназначаемых для добавления или удаления адресов IP, должны применяться следующие правила:

D1. При добавлении к соединению адреса IP подразумевается, что адрес IP не считается полностью добавленным к соединению до приема сообщения REL-ACK. Это означает, что до получения подтверждения на содержащее добавление сообщение REL-REQ отправитель не должен пользоваться новым адресом IP как источником для любого пакета SCTP.

D2. После получения подтверждающего адрес IP сообщения REL-ACK оконечный пункт может начать использование добавленного адреса IP в качестве адреса источника.

D3. Если оконечный пункт получает сообщение об операционной ошибке, указывающее, что запрос о добавлении или удалении адреса IP не понят, он должен распознать неуспешное окончание операции и не должен предпринимать попыток передачи равноуровневому объекту следующего запроса о добавлении или удалении.

D4. При удалении адреса IP из соединения данный адрес IP должен рассматриваться как часть соединения до получения сообщения REL-ACK. Это означает, что любые датаграммы, полученные до приема сообщения REL-ACK об удаляемом адресе IP, должны рассматриваться как часть текущего соединения.

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

D6. Если получен запрос на удаление последнего адреса IP от равноуровневого оконечного пункта, получатель запроса должен направить сообщение об операционной ошибке с причиной, установленной в новый код ошибки Запрос удаления последнего адреса IP (Request to delete last IP address). Запрошенное удаление не должно выполняться либо оказывать какое-то влияние, кроме передачи сообщения об операционной ошибке.

D7. После приема сообщения REL-ACK об удалении адреса IP оконечный пункт не должен использовать удаленный адрес IP как адрес источника для любого пакета SCTP.

В течение временного интервала между передачей сообщения REL-REQ и приемом REL-ACK может существовать возможность принимать неупорядоченные данные порций информации DATA. Эти моменты иллюстрируются следующими примерами:

Оконечный пункт А Оконечный пункт Z

REL-REQ [Add-IPX]..............------>

/----REL-ACK

-------Новая порция информации DATA:

У / Пункт назначения 1Р:Х

Л---------------J

В приведенном выше примере новый адрес IP (X) добавляется к оконечному пункту А. Однако, из-за переупорядочивания пакетов в сети новая порция информации DATA передается и прибывает на оконечный пункт А до того, как сообщение REL-ACK подтверждает добавление адреса к соединению.

Похожая проблема существует и при удалении адреса IP:

Оконечный пункт А Оконечный пункт Z

/----------Новая порция информации DATA:

/ Пункт назначения 1Р:Х

REL-REQ [DEL-IP:X]----/---......-----►

4-----------/-.........-----REL-ACK

В данном примере показана порция информации DATA, направленная на 1Р:Х (который должен быть удален), полученная после выполнения удаления.

В случае добавления оконечный пункт должен рассматривать новое добавление адреса IP как пригодное для получения данных при соединении в течение времени ожидания сообщения REL-ACK. Оконечный пункт не должен отправлять данные с нового адреса как с источника до получения сообщения REL-ACK, но может получать неупорядоченные данные, а также не должен обрабатывать эти данные как датаграмму. Он может оставить эти данные без внимания или рассматривать их как часть соединения, но не должен отвечать на них действием ABORT.

В случае удаления оконечный пункт может ответить на запоздавший пакет DATA как на датаграмму или кратковременно удерживать удаляемый адрес IP в качестве действующего. Если он обрабатывает пакет DATA, равноуровневый объект не производит действия ABORT (как только будет передано сообщение ABORT, равноуровневый объект удалит адрес IP из соединения). Если оконечный пункт выбирает временное удержание адреса IP в числе действующих, он не должен удерживать действительность адреса дольше двойного интервала RTO, установленного для удаляемого пункта назначения.

4.12. Аспекты информационной безопасности

Можно выделить следующие общие аспекты безопасности.

4.12.1. Аутентификация

Информация передается/принимается от партнера, который известен или с которым установлены доверительные отношения (обмен информацией проводится известными друг другу сторонами). До недавнего времени количество взаимных межстанционных соединений узлов ОКС №7, принадлежащих разным операторам, было относительно ограниченным, и эти операторы были достаточно известны друг другу (а иногда имели между собой доверительные отношения). Из-за роста потребности в установлении взаимных соединений между различными операторами на добровольной или обязательной основе доверительные отношения исчезают. Это означает, что оператор не будет принимать всех сообщений ОКС №7, переданных ему другим оператором. Указанное достигается применением процедуры скрининга (ограничения) МТР и SCCP: в зависимости от информации, содержащейся в различных полях МТР (например, ОРС) и/или полях SCCP (например, адрес вызывающей стороны, SNN) сообщение может быть отклонено либо принято для транспортировки по сети или к оконечному пункту сети. В наихудшем случае возможно введение ограничений на прикладном уровне (например, для пользовательской информации в сообщении IAM или в компоненте INVOKE ТС, ограничение наименования контекста приложения).

Шлюз ОКС №7 с применением ограничений по применению ведет себя аналогично системе firewall.

4.12.2. Целостность

Информация в процессе транзита не должна модифицироваться. На сети общего пользования целостность сообщения не гарантируется. Если оно передается через сеть IP, целостность может быть гарантирована на двух уровнях.

1. Уровень IP с. использованием IPSEC, представляющий собой эквивалент обеспечения целостности на базе уровня звена данных ОКС №7. Распределение паролей в основном ограничивается сетью данного оператора.

2. Целостность из конца в конец с использованием ТСАР, этот вопрос предназначен для дальнейших исследований в рамках МСЭ.

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

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

4.12.4. Доступность

При предоставлении некоторых услуг выдвигается требование, чтобы оконечный пункт связи должен оставаться в рабочем режиме при любых обстоятельствах. К примеру, узлы ОКС №7 должны оставаться активными в течение 99,999% времени.

4.12.5. Аспекты безопасности SIGTRAN

Внедрение SCTP представляет лишь попытку повышения доступности сети и не содержит в своих сообщениях никаких элементов, имеющих непосредственное отношение к функциям аутентификации, целостности и конфиденциальности. Указанные возможности находятся в зависимости от протоколов IPSEC, а также архитектуры и/или характеристик безопасности пользовательских протоколов.

Единственной функцией SCTP, имеющей отношение к безопасности, является функция обеспечения целостности сообщений, выполняемая проверочным суммированием. Эта функция обязательна даже при неиспользовании IPSEC. В соединениях SCTP рекомендуется сквозное использование IPSEC. Применение IPSEC на части тракта SCTP не означает возможности отказаться от проверочного сумми-

рования, так как не имеет отношения к сквозной транспортировке. Основным требованием является безусловное активизирование IPSEC.

4.12.5.1. Механизм cookie и вредное влияние отказа в обслуживании (Denial-of-Service - DOS)

В протоколе SCTP механизм cookie является средством против вредного влияния отказа в обслуживании (Denial-of-Service - DOS). При таком влиянии на единственный оконечный пункт направляются многочисленные порции информации инициализации соединения от неавторизованного источника с недействительным адресом в датаграммах. Тогда очень скоро все ресурсы оказываются задействованными, а нормальные пользователи получают отказ на обслуживание ввиду перегрузки ресурсов оконечного узла или хост-компьютера. Соответствующий механизм противодействия описан ниже.

При приеме порции IN1T выполняется кодирование информации блока управления передачей (Transmission Control Block - ТСВ). Процедурой cookie эта информация передается на инициирующий узел в сообщении INIT ACK. На принимающем узле не производится привязка информации ТСВ, так как вся информация закодирована операцией cookie и передается обратно в сообщении СООК1ЕАСК (в то же время, ТСВ уже будет в действительности привязан к информации cookie, а ассоциативная связь установлена полностью).

Так как в случае вредного влияния DOS сообщение INITACK передается на недействительный адрес, в обратном направлении не передается сообщение COOKIEACK, а ресурс входящего узла не задействуется.

Если же INIT ACK передается на действительный адрес, происходит резервирование ресурсов и установление соединения. В результате становится возможно обнаружить инициатора соединения (если он, разумеется, действительно инициирует связь). После обмена информацией cookie для распознавания имени хост-компьютера может включаться запрос DNS (если на адресе оконечной точки применяется опция хост-компьютера). Этого не разрешается делать ранее ввиду задействования в таком случае ресурсов (на время ожидания ответа на запрос DNS) с их зависанием в состоянии между сообщениями INIT ACK и СООК1Е АСК, что сделает процедуру cookie бесполезной для приемной стороны соединения.

Даже с принятием таких мер возможен случай вредного влияния DOS DNS (DdoS). Например, X передает сообщения INIT с именем a.example.com на адреса Bl, В2, ... В1000000. Тогда после обмена ин-

формацией cookie 1 ООО ООО хост - компьютеров будут пытаться: 1) выйти на сервер DNS адреса a.example.com; 2) осуществлять передачу в сторону А. Это означает, что X имеет пропускную способность, достаточную для передачи пакетов INIT всем адресам В или, как минимум, превышающую возможности доступа к сети со стороны А. Указанное предположение не является невероятным. Подобное справедливо при рассмотрении сообщения INIT-ACK. В обоих Случаях example.com будет считать такой трафик DNS исходящим откуда угодно, но ничто не будет указывать на X непосредственно.

4.12.5.2. Процедура Fingerprinting для SCTP

Различными приложениями в ответных сообщениях могут предъявляться различные опознавательные знаки. В соответствии со спецификациями протокола SCTP, рекомендуется передавать только базовую необходимую информацию. Однако, Fingerprinting посредством анализа определенных параметров без выхода за пределы синтаксиса сообщения дает возможность вычисления поставщика конкретной реализации, чье имя не должно указываться явным образом. К примеру, одним из поставщиков реализации ТСАР поле длины транзакции может устанавливаться в значение, не используемое больше никем.

4.12.5.3. Вредное влияние ACK-Splitting

Вредное влияние ACK-Splitting заключается в разделении передаваемого подтверждения на сегменты, подтверждающие прием только части сообщения. Обычно на каждое принятое сообщение принимающая сторона должна отправлять обратно единственное подтверждение. Для сети результатом вредного воздействия ACK-Splitting будет рост окна перегрузок для каждого принимаемого с разделением сообщения АСК.

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

4.12.5.4. Информационная безопасность при туннелировании

Туннелирование SCTP является объектом тех же требований к информационной безопасности, что и процесс передачи сообщений SCTP через IP. Могут использоваться те же механизмы безопасности, то