Протоколы Internet
Протоколы Novell (IPX/SPX)
4.2.1 Протоколы Novell (IPX/SPX)
Семенов Ю.А. (ГНЦ ИТЭФ)
Межсетевой протокол IPX - (Internetwork Packet eXchange; Novell (См. также А.В.Фролов, Г.В.Фролов, “Локальные сети персональных компьютеров. Использование протоколов IPX, SPX, NETBIOS. Москва, “Диалог-МИФИ”, 1993), [13]) соответствует сетевому уровню модели ISO, до какой-то степени это аналог IP-протокола в Интернет. IPX-протокол может работать совместно с SPX при обеспечении обменов, ориентированных на соединение, где гарантируется доставка информации. IPX произошел от протокола XNS (Xerox Network Services) и имеет ряд уникальных черт. Так IPX может использовать различные схемы инкапсуляции в зависимости от физической сетевой среды. В операционной среде MS-DOS за реализацию протокола IPX отвечает программа IPX.COM или IPXODI.COM. Оболочка же системы NetWare (NETX.COM) и DOS Requester (VLM.COM) используют протокол IPX для пересылки запросов файл-серверу.
Первоначально пакеты Novell инкапсулировались в кадры IEEE 802.3. В настоящее время схема инкапсуляции поддерживает 802.2 и протокол SNAP (Sub-Network Access Protocol).
Протоколы сетей ATM
4.3.5 Протоколы сетей ATM
Семенов Ю.А. (ГНЦ ИТЭФ)
Это не значит, что доступны лишь указанные скорости, интерфейсы позволяют мультиплексировать большое число каналов с самыми разными скоростями обмена. Но мультиплексирование на таких частотах представляет собой значительную проблему. Определенные трудности представляет то обстоятельство, что в ATM трудно реализовать обмен без установления соединения (аналог utp в Интернет)
Протокол ATM (asynchronous transfer mode; см. также А.Н. Назаров, М.В. Симонов. "АТМ. Технология высокоскоростных сетей". ЭКО-Трендз, М. 1998) является широкополосной версией ISDN, работает на скорости 150,52 Мбит/с с пакетом постоянной длины и минимальным заголовком. Слово асинхронный в названии означает, что тактовые генераторы передатчика и приемника не синхронизованы, а сами ячейки передаются и мультиплексируются по запросам. При мультиплексировании используется статистическая технология. Асинхронная передача не предполагает упорядочивания ячеек по каналам при пересылке. ATM поддерживает аппаратную и пакетную коммутацию.
Каждый пакет ATM имеет 53 байта (в англоязычной документации пакеты ATM носят название cell (ячейка), этот термин введен, чтобы отличить пакеты ATM от пакетов низкоскоростных каналов), из них 48 байт несут полезную информацию (что для случая передачи звука, соответствует 6 мс). Для выделения пакета из потока используются такие же, как в ISDN разделительные байты (0x7E). Заголовок пакета содержит лишь 5 байт и предназначен главным образом для того, чтобы определить принадлежит ли данный пакет определенному виртуальному каналу. Отсутствие контроля ошибок и повторной передачи на физическом уровне приводит к эффекту размножения ошибок. Если происходит ошибка в поле идентификатора виртуального пути или виртуального канала, то коммутатор может отправить ячейку другому получателю. Таким образом, один получатель не получит ячейку, а другой получит то, что ему не предназначалось.
Виртуальный канал в ATM формируется также как и в ISDN. Формально эта процедура не является частью ATM-протокола. Сначала здесь формируется сигнальная схема, для этого посылается запрос с VPI=0 и VCI=5. Если процедура завершилась успешно, можно начинать формирование виртуального канала. При создании канала могут использоваться 6 разновидностей сообщений.
setup - запрос формирования канала.
call proceeding - запрос в процессе исполнения.
connect - запрос принят.
connect ACK - подтверждение получения запроса.
release - сообщение о завершении.
release compleate - подтверждение получения сообщения release.
Схема обмена сообщениями при установлении (и разрыве) виртуального соединения показана на рис. 4.3.5.1. Предполагается, что между ЭВМ-инициализатором и ЭВМ-адресатом находится два ATM-переключателя. Каждый из узлов по пути к месту назначения при получении запроса setup откликается, посылая сообщение call proceeding. Адрес места назначения указывается в сообщении setup. В ATM используется три вида адресов. Первый - имеет 20 байт и имеет структуру OSI-адреса. Первый байт указывает на вид адреса (один из трех). Байты 2 и 3 указывают на принадлежность стране, а байт 4 задает формат последующей части кода адреса, которая содержит 3 байта кода администрации (authority), 2 байта домена, 2 байта области и 6 байтов собственно адреса. Во втором формате байты 2 и 3 выделены для международных организаций, а не стран. Остальная часть адреса имеет тот же формат, что и в варианте 1. Третий формат является старой формой (CCITT E.164) 15-цифровых десятичных телефонных номеров ISDN. В ATM не специфицировано никакого алгоритма маршрутизации. Для выбора маршрута (от коммутатора к коммутатору) используется поле VCP. VCI используется лишь на последнем шаге, когда ячейка посылается от переключателя к ЭВМ. Такой подход упрощает маршрутизацию отдельных ячеек, так как при этом анализируется 12- а не 28-битовые коды. В каждом коммутаторе (переключателе) формируются специальные таблицы, которые решают проблему переадресации ячеек.
Следует обратить внимание на то, что виртуальный канал (circuit) и виртуальный проход (path) в данном контексте не тождественны. Виртуальный проход (маршрут) может содержать несколько виртуальных каналов. Виртуальные каналы всегда являются полностью дуплексными.
Рис. 4.3.5.1. Обмен сообщениями при установлении и разрыве виртуального соединения
Сети ATM допускают создание мультикастных каналов. Такой канал имеет одного отправителя и много получателей. Первый канал формируется обычным путем, последующие участники сессии подключаются позднее путем посылки сообщения add party.
За видимую простоту ячеек приходится платить тем, что управляющая информация передается в общем информационном потоке. Высокая скорость передачи данных требует применения аппаратно реализованных маршрутных таблиц на каждом переключателе пакетов. На рис. 4.3.5.2 представлен формат заголовка пакета ATM. Заголовок обеспечивает два механизма маршрутизации пакетов:
VPI (virtual path identifier - виртуальный идентификатор маршрута) обеспечивает соединение точка-точка, но маршрут не является фиксированным и задается непосредственно перед началом пересылки с использованием сигнальных сообщений. Слово “виртуальный” означает, что пакеты передаются от узла к узлу в соответствии с VPI.
VCI (virtual call identifier - виртуальный идентификатор запроса) запросы осуществляются в соответствии с виртуальным маршрутом, заданным VPI.
Эти два субполя вместе образуют поле маршрута, которое занимает 24 бита.
Рис. 4.3.5.2 Формат заголовка ATM-пакета (сетевой интерфейс пользователя - UNI)
Для интерфейса сеть-сеть (NNI) используется ячейка с несколько иным форматом заголовка. Там весь первый октет выделен для VPI, а поле GFC отсутствует.
GFC
VPI
VCI
PT
RES
CLP
HEC
Таблица 4.3.5.1.
vci |
vpi |
Назначение |
| 0 | только 0 | Неопределенная ячейка |
| 1 | все | Мета управление |
| 3 | все | Сетевое управление VP-каналом |
| 4 | все | vp-управление для соединения между конечными точками |
| 5 | все | Управление доступом по схеме точка-точка |
| 6 | все | Ячейка управления ресурсами (для подавления перегрузки) |
| 16 | только 0 | UNI (snmp) управление сетью |
Таблица 4.3.5.2. Заданные значения поля PT (payload type identifier)
| PT | Назначение ячейки | Взаимодействие пользователь-пользователь |
| 000 | Пользовательские данные (перегрузка отсутствует) | Нет |
| 001 | Пользовательские данные (перегрузка отсутствует) | Нет |
| 010 | Пользовательские данные (имеет место перегрузка) | Да |
| 011 | Пользовательские данные (имеет место перегрузка) | Да |
| 100 | Ячейка виртуального канала oam сегментного потока f5 | |
| 101 | Соединение точка-точка oam сегментного потока f5 | |
| 110 | Управление ресурсами | |
| 111 | Зарезервировано |
Передача голоса на скоростях 64 Кбит/с. Один ATM-пакет соответствует 6 мсек.
Передача музыки с использованием схемы кодирования MUSICAM.
Так как для случая изображения передается только переменная часть картинки, atm идеально подходит для решения такого рода задач.
Задачи управления решаются менее экономно, но, тем не менее, достаточно эффективно (предусмотрено несколько приоритетов для управления потоками данных).
В ATM предусмотрено несколько категорий услуг (таблица 4.3.5.3).
Таблица 4.3.5.3. Типы категорий ATM-услуг
| Класс | Описание | Пример |
| cbr | Постоянная скорость передачи | Канал Т1 |
| rt-vbr | Переменная скорость передачи (реальное время) | Видеоконференции |
| nrt-vbr | Пременная скорость передачи (нереальное время) | Мультимедиа по электронной почте |
| abr | Доступная скорость передачи | Просмотр web-информации |
| ubr | Не специфицированная скорость передачи | Пересылка файлов в фоновом режиме |
Класс VBR содержит в себе два подкласса - обычный и для реального времени (см. таблицу выше). ATM в процессе доставки не вносит никакого разброса ячеек по времени. Случаи потери ячеек игнорируются.
Класс ABR предназначен для работы в условиях мгновенных вариаций трафика. Система гарантирует некоторую пропускную способность, но в течение короткого времени может выдержать и большую нагрузку. Этот класс предусматривает наличие обратной связи между приемником и отправителем, которая позволяет понизить загрузку канала, если это необходимо.
Класс UBR хорошо пригоден для посылки IP-пакетов (нет гарантии доставки и в случае перегрузки неизбежны потери).
atm использует исключительно модель с установлением соединения (здесь нет аналогий с UDP-протоколом). Это создает определенные трудности для управления трафиком с целью обеспечения требуемого качества обслуживания (QoS). Для решения этой задачи используется алгоритм GCRA (generic rate algorithm). Работа этого алгоритма проиллюстрирована на рис. 4.3.5.3.
Рис. 4.3.5.3. Иллюстрация работы алгоритма GCRA
gcra имеет два параметра. Один из них характеризует максимально допустимую скорость передачи (PCR - peak cell rate; T=1/PCR - минимальное расстояние между ячейками), другой - допустимую вариацию значения скорости передачи (CDVT=L). Если клиент не собирается посылать более 100000 ячеек в секунду, то Т=10 мксек. На рис. 4.3.5.3 представлены разные варианты следования ячеек. Если ячейка приходит раньше чем T-t, она считается неподтверждаемой и может быть отброшена. Ячейка может быть сохранена, но при этом должен быть установлен бит CLP=1. Применение бита CLP может быть разной для разных категорий услуг (смотри таблицу 4.3.5.3.). Данный механизм управления трафиком сходен с алгоритмом "дырявое ведро", описанным в разделе "Сети передачи данных".
Можно вычислить число подтверждаемых ячеек N, которые могут быть переданы при пиковом потоке ячеек PCR=1/t. Пусть время ячейки в пути равно d. Тогда N = 1 + (l/(T-d)). Если полученное число оказалось нецелым, оно должно быть округлено до ближайшего меньшего целого.
Трудно устранимой проблемой для atm является предотвращение перегрузки на промежуточных коммутаторах-переключателях. Коммутаторы могут иметь 100 внешних каналов, а загрузка может достигать 350000 ячеек/сек. Здесь можно рассматривать две задачи: подавление долговременных перегрузок, когда поток ячеек превосходит имеющиеся возможности их обработки, и кратковременные пиковые загрузки. Эти проблемы решаются различными способами: административный контроль, резервирование ресурсов и управление перегрузкой, привязанное к уровню трафика.
В низкоскоростных сетях с относительно медленно меняющейся или постоянной загрузке администратор вмешивается лишь при возникновении критической ситуации и предпринимает меры для понижения скорости передачи. Очень часто такой подход не слишком эффективен, так как за время доставки управляющих команд приходят многие тысячи ячеек. Кроме того, многие источники ячеек в ATM работают с фиксированной скоростью передачи (например, видеоконференция). Требование понизить скорость передачи здесь достаточно бессмысленно. По этой причине в АТМ разумнее предотвращать перегрузку. Но для трафика типа CBR, VBR и UBR не существует никакого динамического управления перегрузкой и административное управление является единственной возможностью. Когда ЭВМ желает установить новый виртуальный канал, она должна охарактеризовать ожидаемый трафик. Сеть анализирует возможность обработки дополнительного трафика с учетом различных маршрутов. Если реализовать дополнительный трафик нельзя, запрос аннулируется. В отсутствии административного контроля несколько широкополосных пользователей могут блокировать работу массы узкополосных клиентов сети, например, читающих свою почту.
Резервирование ресурсов по своей сути близко административному контролю и выполняется на фазе формирования виртуального канала. Резервирование производится вдоль всего маршрута (во всех коммутаторах) в ходе реализации процедуры setup. Параметрами резервирования может быть значение пикового значения полосы пропускания и/или средняя загрузка.
Для типов сервиса CBR и VBR отправитель даже в случае перегрузки не может понизить уровень трафика. В случае UBR потери не играют никакой роли. Но сервис ABR допускает регулирование трафика. Более того, такое управление здесь весьма эффективно. Существует несколько механизмов реализации такого управления. Так предлагалось, чтобы отправитель, желающий послать блок данных, сначала посылал специальную ячейку, резервирующую требуемую полосу пропускания. После получения подтверждения блок данных начинает пересылаться. Преимуществом данного способа следует считать то, что перегрузки вообще не возникает. Но данное решение не используется из-за больших задержек (решение ATM-форума).
Другой способ сопряжен с посылкой коммутаторами специальных ячеек отправителю в случае возникновения условий перегрузки. При получении такой ячейки отправитель должен понизить скорость передачи вдвое. Предложены различные алгоритмы последующего восстановления скорости передачи. Но и эта схема отвергнута форумом atm из-за того, что сигнальные ячейки могут быть потеряны при перегрузке. Действительно данный алгоритм не всегда можно признать разумным. Например, в случае, когда коммутатор имеет 10 каналов с трафиком по 50 Мбит/с и один канал с потоком в 100 кбит/c, глупо требовать понижения трафика в этом канале из-за перегрузки.
Третье предложение использует тот факт, что граница пакета помечается битом в последней ячейке. Коммутатор просматривает входящий поток и ищет конец пакета, после чего выбрасывает все ячейки, относящиеся к следующему пакету. Этот пакет будет переслан позднее, а отбраcывание M ячеек случайным образом может вынудить повторение передачи m пакетов, что значительно хуже. Данный вариант подавления перегрузки был также не принят, так как выброшенный пакет совсем не обязательно послан источником, вызвавшим перегрузку. Но этот способ может быть использован отдельными производителями коммутаторов.
Обсуждались решения, сходные с тем, что используется в протоколе TCP "скользящее окно". Это решение требует слишком большого числа буферов в коммутаторах (как минимум по одному для каждого виртуального канала). После длинных дискуссий был принят за основу совершенно другой метод.
После каждых М информационных ячеек каждый отправитель посылает специальную RM-ячейку (resource management). Эта ячейка движется по тому же маршруту, что и информационные, но RM-ячейка обрабатывается всеми коммутаторами вдоль пути. Когда она достигает места назначения, ее содержимое просматривается и корректируется, после чего ячейка посылается назад отправителю. При этом появляются два дополнительных механизма управления перегрузкой. Во-первых, RM-ячейки могут посылаться не только первичным отправителем, но и перегруженными коммутаторами в направлении перегрузившего их отправителя. Во-вторых, перегруженные коммутаторы могут устанавливать средний PTI-бит в информационных ячейках, движущихся от первоисточника к адресату. Но даже выбранный метод подавления перегрузки не идеален, так как также уязвим из-за потерь управляющих ячеек.
Управление перегрузкой для услуг типа abr базируется на том, что каждый отправитель имеет текущую скорость передачи (ACR - actual cell rate), которая лежит между MCR (minimum cell rate) и PCR (peak cell rate). Когда происходит перегрузка, ACR уменьшается, но не ниже MCR. При исчезновении перегрузки acr увеличивается, но не выше PCR. Каждая RM-ячейка содержит значение загрузки, которую намеривается реализовать отправитель. Это значение называется ER (explicit rate). По пути к месту назначения эта величина может быть уменьшена попутными коммутаторами. Ни один из коммутаторов не может увеличивать ER. Модификация ER может производиться как по пути туда, так и обратно. При получении RM-ячейки отправитель может скорректировать значение ACR, если это необходимо.
С точки зрения построения интерфейса и точек доступа (T, S и R) сеть ATM сходна с ISDN (см. рис. 4.3.3.1 ).
Для физического уровня предусмотрены две скорости обмена 155,52 и 622,08 Мбит/с. Эти скорости соответствуют уровням иерархии SDH STM-1 и 4*STM-1. При номинальной скорости 155.52 Мбит/с пользователю доступна реально скорость обмена 135 Мбит/c, это связано с издержками на заголовки и управление. Для ATM используются коаксиальные кабели, скрученные пары (раздел 2.1). Это обеспечивает балансировку передающей линии по постоянному напряжению, но удваивает частоту переключения практически вдвое. Скрамблерный метод не меняет частоту переключения, но его эффективность зависит от передаваемой информации. CMI предпочтительней для 155 Мбит/с. В настоящее время используется две схемы передачи данных применительно к ATM: базирующийся на потоке пакетов (cell stream) и на SDH структурах. В первом случае мы имеем непрерывный поток 53-октетных пакетов, во втором эти пакеты уложены в STM-1 кадры. Управляющие сообщения располагаются в заголовках секции и пути кадра SDH. AAL (ATM adaptation layer) служит для адаптации различных видов сервиса к требованиям ATM-уровня. Каждый вид услуг требует своего AAL-протокола. Главной целью AAL является обеспечение удобства при создании и исполнении программ прикладного уровня. Для всех AAL определены два субуровня:
| SAR | (segmentation and reassemble) делит пакеты высокого уровня, передает atm и наоборот (сборка сообщений из сегментов). |
| CS | (convergent sub-layer) зависит от вида услуг (обработка случаев потери пакета, компенсация задержек, мониторирование ошибок и т.д.). Этот подуровень может в свою очередь делиться на две секции: CPCS (common part convergence sublayer) – общая часть субуровня конвергенции и SSCS (service-specific convergence sublayer) – служебно-ориентированный подуровень конвергенции (последний может и отсутствовать). |
/p> aal-протоколы управляются значениями следующих переменных:
Скорость обмена (постоянная или переменная)
Режим соединения (с установлением связи или без)
Синхронизация ( требуется или нет синхронизация между отправителем и получателем)
В настоящее время определены четыре класса услуг, которые могут требовать или нет синхронизации между отправителем и получателем, осуществлять обмен при постоянной или переменной частоте передачи бит, с установлением связи или без. Особенности этих видов услуг для адаптивного уровня систематизированы в таблице 4.3.5.4. Каждая из услуг имеет свой AAL протокол.
Таблица 4.3.5.4.
Особенности видов услуг для адаптивного уровня
Класс a (AAL1) |
Класс b (AAL2) |
Класс c (AAL3/4 или 5) |
Класс d (AAL3/4 или 5) |
|
| Синхронизация работы отправителя и получателя | необходима | необходима | не нужна | не нужна |
| Частота следования битов | Постоянная | Переменная | Переменная | Переменная |
| Режим соединения | С соединением | С соединением | С соединением | Без соединения |
синхронизацию передатчика и приемника;
передачу данных с фиксированной скоростью;
индикацию потери и искажения данных, если эти ошибки не устраняются на уровне адаптации;
передачу от отправителя получателю информации о структуре передаваемых данных.
Для решения этих задач AAL первого уровня должен устранять разброс задержек, выявлять ячейки, доставленные не по адресу, и потерянные ячейки, сегментацию пакетов и последующее их восстановление, выполнять мониторирование ошибок в управляющей информации протокола AAL-PCI (protocol control information). Характер обмена здесь строго ориентирован на соединение. AAL-1 использует субуровни конвергенции и SAR. Субуровень конвергенции обеспечивает постоянство скорости передачи ячеек. AAL-1 конвергенции не имеет какого-то специфического протокольного заголовка. Этот субуровень разбивает входные сообщения на 46- или 47-байтные блоки и передает их субуровню SAR для пересылки.
Структура протокольной части информационного поля ячейки SAR-pdu представлена на рис. 4.3.5.4
CSI позволяет приемнику распознать уровень конвергенции. Подуровень SAR получает значение SN (порядковый номер) для каждого 47-октетного блока данных от подуровня конвергенции. Поле SNR (sequence number protection - контрольная сумма) служит для обнаружения и исправления ошибок в заголовке, в качестве производящего полинома используется G(x)= x3 + x + 1. Один из битов SNP- представляет собой бит четности. Если CSI=1, то после поля SNP следует однобайтовое поле указатель, которое используется для определения положения начала следующего сообщения (значения 0-92; старший бит поля указатель зарезервирован на будущее). Поле данных в этом варианте имеет 64 байт.
Для сжатой аудио и видео информации скорость передачи может варьироваться в широких пределах. Ведь многие схемы предусматривают периодическую отправку полного видеокадра при последующей передаче транспортируются лишь отличия последовательных кадров. Уровень адаптации 2-го типа предоставляет вышестоящему уровню возможность синхронизовать передатчик и приемник, осуществлять обмен с изменяющейся скоростью, оповещение об ошибках и потерях ячеек. Структура ячейки AAL 2-го типа показана на рис. 4.3.5.5 (субуровень SAR). Из-за переменной скорости передачи заполнение ячеек может быть неполным.
Рис. 4.3.5.4. Структура PDU подуровня SAR ATM 1-го типа (AAL1)
| CSI | (convergence sublayer indicator) – индикатор подуровня конвергенции |
| SN | (sequence number) – номер по порядку |
| SNP | (sequence number protection) – защита номера последовательности |
Рис. 4.3.5.5. Структура PDU подуровня SAR ATM 2-го типа (AAL2)
| IT | (information type) – тип данных. Служит для указания начала, продолжения или окончания сообщения |
| LI | (length indicator) – индикатор длины. Указывает число октетов в поле данных |
| CRC | Контрольная сумма |
Уровень адаптации 3/ 4 типов предназначен для передачи данных как в режиме с установлением соединения, так и без него. Раньше службам С и D были выделены разные типы уровня адаптации, позднее они были объединены. Определены два типа обмена: сообщение и поток. В первом случае блок данных передается в одном интерфейсном блоке (IDU). Сервисные блоки данных могут иметь переменную длину. В режиме поток сервисный блок данных передается через интерфейс уровня адаптации в одном или нескольких IDU. В этом режиме может быть реализована услуга “внутренний контейнер”. Здесь допускается и прерывание передачи, частично переданный блок теряется. AAL3/4 допускает организацию нескольких сессий одновременно (например, несколько удаленных login). Структура протокольного блока данных подуровня SAR 3/4 типа представлена на рис. 4.3.5.6. Длина поля данных (PDU) составляет 44 байта. Заметим, что AAL3/4 имеет два уровня издержек - 8 байт добавляется для каждого сообщения и 4 избыточных байта приходятся на каждую ячейку, это достаточно много особенно для коротких сообщений.
Рис. 4.3.5.6. Структура pdu подуровня SAR ATM 3/4-го типов
| ST | (segment type) – тип сегмента. Начало сообщения – 10 (BOM – beginning of message), продолжение – 00 (COM – continuation of message), завершение сообщения – 01 (EOM – end of message), односегментное сообщение – 11; |
| SN | (sequence number) – номер по порядку; |
| MID | (multiplexing identifier) – идентификатор мультиплексирования для протокола 4-го уровня (позволяет мультиплексировать до 1024 пользователей для одного соединения). Поле служит для определения того, к какой из активных сессий принадлежит данная ячейка. |
| li | длина заполнения поля данных. |
Рис. 4.3.5.7. Формат блока данных подуровня конвергенции AAL 3/4-типа
| CPI | (common part indicator) – однооктетный индикатор общей части, используется при интерпретации последующих полей; |
| BTAG | (beginning tag) – однооктетная метка начала, в сочетании с ETAG определяет границы протокольного блока данных (PDU); |
| BAsize | (buffer allocation size) – емкость буфера, сообщает получателю максимальный размер буфера. Поле занимает 2 байта; |
| PAD | заполнитель, обеспечивает кратность поля данных 4 октетам; |
| AL | (alignment) – выравнивание, заполняется нулями; |
| ETAG | (end tag) – метка конца (один октет); |
| Длина | задает протяженность cpcs-pdu; |
| CPCS-PDU | (common part convergence sublayer – protocol data unit) – протокольный блок данных общей части подуровня конвергенции |
Рис. 4.3.5.8. Формат ячейки SAR-PDU 5-го типа (AAL5)
Рис. 4.3.5.8a. Формат сообщения AAL5 субуровня конвергенции
| UU | (user to user) – поле необходимо для верхних уровней, чтобы обеспечить мультиплексирование; |
| Длина | двухоктетное поле длины поля данных (PDU); |
| CRC | 4-октетная контрольная сумма; |
Рис. 4.3.5.9. Положение уровней ATM в универсальной модели
Верхние уровни управления для ATM базируются на рекомендациях ccitt I450/1 (Q.930/1). В случае использования ATM для Интернет значение MTU по умолчанию равно 9180 (RFC-1626), так как фрагментация IP-дейтограмм крайне нежелательна (AAL). Работа протоколов TCP/IP поверх ATM описана в документах RFC-1483, -1577, -1626, -1680, -1695, -1754, -1755, -1821, -1926, -1932 (полужирным шрифтом выделены коды документов, являющиеся стандартами Интернет). Ниже на рис. 4.3.5.10 показано, как пакеты atm размещаются в кадрах STM-1 (виртуальный контейнер VC-4).
Рис. 4.3.5.10. Размещение atm пакетов в STM-1 кадре
В STM-1 для передачи ячеек выделяется полоса пропускания
Форматы адресов согласно спецификации интерфейса “пользователь-сеть” представлены на рис. 4.3.5.11.
Рис. 4.3.5.11. Формат DCC ATM с числовым кодом страны.
| AFI | (authority and format identifier) – идентификатор формата и привилегий. |
| DCC | (data country code) – код данных страны (стандарт МОС 3166). |
| DFI | (DSP format identifier) – идентификатор формата DSP. |
| DSP | (domain specific part) – часть, зависящая от домена. |
| AA | (administrative authority) – административное субполе. |
| RSVD | (reserved) – резерв на будущее. |
| RD | (routing domain) – область маршрутизации. |
| AREA | идентификатор зоны. |
| ESI | (end system identifier) – идентификатор оконечной системы. |
| SEL | (selector) – селектор. |
| IDI | (initial domain identifier) – идентификатор исходной области. |
| HO | (higher order) – старшая часть. |
Важную роль в управлении сетями АТМ играет информация OAM(operations and maintenance). Здесь осуществляется тесное взаимодействие с потоками управления sdh (F1-F5).
F1 – поток данных oam уровня регенерационной секции SDH.
F2 - поток данных oam цифровой мультиплексорной секции SDH.
F3 - поток данных oam уровня пути обмена SDH.
F4 - поток данных oam виртуального пути АТМ.
F5 - поток данных oam виртуального канала АТМ.
Рис. 4.3.5.12. Формат адреса Е.164 NSAP
Рис. 4.3.5.13. Структура номеров
Код страны (СС –country code) занимает от одной до трех цифр (из 15).
Маршрутизация в atm отличается от аналогичных процессов в сетях с коммутацией пакетов. Сети АТМ в основном ориентированы на соединение. Ячейки транспортируются по уже выбранному маршруту через коммутаторы АТМ в соответствии со значениями идентификаторов виртуального пути и виртуального канала. Вычисление маршрута осуществляется на специальном сервере. Потоки информации F4 или F5 принимаются и обрабатываются устройствами, которые формируют виртуальные пути или каналы. Формат информационного поля ячейки oam показан на рис. 4.3.5.14. Поток информации oam F4 уровня виртуального пути для идентификации потока точка-точка использует идентификатор виртуального канала VCI=4, а для сегментных потоков VCI=3.
Рис. 4.3.5.14. Формат ячейки OAM F4
Поток ячеек OAM F5 уровня виртуального канала каких-либо специальных идентификаторов виртуальных путей не использует. В заголовках ячеек потока oam F5 типа точка-точка в поле типа данных (PT) записывается код 100, а для сегментных потоков виртуальных каналов PT=101. Значения кодов полей тип OAM и выполняемой функции приведены в таблице 4.3.5.5. Для решения проблем выявления и локализации отказов в сети АТМ используются ячейки AIS (alarm indication signal – аварийный сигнал), RDI/FERF (remote defect indication/far end reporting failure – указатель отказа на удаленном конце), контроля непрерывности (continuity check) и проверки с применением обратной связи (loopback). Для ячеек AIS и RDI поля тип отказа имеет 8 байт (по умолчанию во все октеты записывается 0х6А), а для указателя места отказа выделено 9 байт. Полезная часть поля данных в этих ячейках равна 45 байтам, из них 28 зарезервировано на будущее.
Таблица 4.3.5.5.
Код поля тип oam |
Назначение |
Код поля тип выполняемой функции |
Назначение |
| 0001 | Обнаружение и определение места отказов (fault management) | 0000 | Указание отказа (AIS) |
| 0001 | Указание на удаленный дефект (RDI/FERF) | ||
| 0100 | Проверка непрерывности (continuity check) | ||
| 1000 | Обратная связь (loopback) | ||
| 0010 | Контроль рабочих характеристик | 0000 | Прямой мониторинг (forward monitoring) |
| 0001 | Сообщение о предыстории (backward reporting) | ||
| 0010 | Мониторирование и предоставление результатов (monitoring and reporting) | ||
| 1000 | Активизация и завершение процессов oam | 0000 | Мониторинг рабочих характеристик (performance monitoring) |
| 0001 | Проверка непрерывности (continuity check) |
Рис. 4.3.5.15. Формат субполей поля данных oam activation/deactivation
Субполе неиспользуемые октеты заполняется байтами 0х6А, а субполя блок РМ - кодами 0000. Значения кодов поля идентификатор сообщения приведены в таблице 4.3.5.6.
Таблица 4.3.5.6.
|
Код поля идентификатор сообщения |
Назначение |
| 000001 | Активация (запрос) |
| 000010 | Подтверждение активации |
| 000011 | Отвержение запроса активации |
| 000101 | Деактивация |
| 000110 | Подтверждение деактивации |
| 000111 | Отвержение запроса деактивации |
Формат ячеек oam типа измерение рабочих характеристик представлен на рис. 4.3.5.16.
Рис. 4.3.5.16. Формат ячеек oam типа измерение рабочих характеристик
В субполя BIP-16 (bit interleaved parity) и счет потерянных ячеек в отсутствии прямого мониторинга по умолчанию заносится код 0х6А, аналогичный код записывается в субполя число ячеек пользователя и результаты анализа в отсутствие обратного мониторинга. В неиспользуемое поле записываются 1 во все биты, если не использована временная метка. Поле порядковый номер мониторинга (MSN – monitoring sequence number) содержит номер ячейки oam типа PM по модулю 256. Поле общее число ячеек пользователя (TUC – total user cell) записывается число пользовательских ячеек, отправленных после последней ячейки OAM типа PM.
Один физический отказ может сгенерировать большое число ячеек OAM. Для блокировки такой возможности введено ограничение на период генерации таких ячеек (> нескольких секунд). Операции проверки тракта, выполняемые с помощью ячеек OAM типа loopback, позволяют выявить место возникновения неисправностей. Формат поля специальных функций ячейки OAM типа loopback отображен на рис. 4.3.5.17 (см. также рис. 4.3.5.14).
Рис. 4.3.5.17. Формат ячейки oam типа loopback
Поле неиспользуемое содержит во всех октетах по умолчанию код 0х6А. Поле индикатор шлейфа содержит 1 при посылке отправителем (остальные семь бит равны нулю), единица заменяется нулем в момент приема. При получении ячейки с индикатором шлейфа, равным нулю, она уничтожается. Поле корреляционная метка используется отправителем для идентификации отклика. Поле идентификатор места шлейфа определяет место, откуда ячейка должна быть послана назад. Если поле содержит все единицы, таким местом является адресат. Поле идентификатор источника служит для распознавания ячейки и ее уничтожения при возвращении.
Предоставление услуг без установления соединения соответствует уровню выше чем АТМ и требует соединения каждого клиента с соответствующим сервером, решающим данную задачу. Большинство локальных и региональных сетей АТМ реализуют именно такой режим. Для передачи данных без установления соединения используется протокол доступа CLNAP (connectionless network access protocol), интерфейс CLAI (connectionless access interface) и сетевой протокол CLNIP (connectionless network interface protocol). Размер поля данных для CLNAP не является постоянным и составляет 9188 октетов, что подразумевает фрагментацию. Эти протоколы работают выше подуровня конвергенции. Соответствующая длина для CLNIP SDU равна 9236 октетам. Формат блока данных CLNIP показан на рис. 4.3.5.18.
Рис. 4.3.5.18. Формат структуры данных протокола CLNIP
| PI | (protocol identifier) – идентификатор протокола. |
| PADLE | (padding length) – длина заполнения. |
| QoS | (quality of service) – качество обслуживания |
| С | (CRC indication bit) – индикатор числа бит в контрольной сумме CRC. |
| HEL | (header extension length) – длина расширения заголовка. |
Из рисунка видно, что на подуровне SAR происходит деление пакета на части и укладка полученных сегментов в поля данных ячеек (48 байт).
Рис. 4.3.5.19. Схема вложения и фрагментации для пакетов CLNAP
| АН | – (alignment header; 4 октета) – поле выравнивания. |
| SAR | – (segmentation and reassemble) – сегментация и сборка. |
| CPCS | - (common part convergence sublayer) общая часть подуровня конвергенции. |
Таблица 4.3.5.7. Значения кодов NLPID
Код nlpid |
Назначение |
| 0х00 | Нулевой сетевой уровень (в atm не используется) |
| 0х80 | SNAP |
| 0х81 | ISO CLNP |
| 0х82 | ISO ESIS |
| 0х83 | ISO ISIS |
| 0хСС | Интернет (IP не является протоколом ISO) |
Рис. 4.3.5.20. Формат IP PDU при транспортировке с использованием AAL5 ATM
Пропускная способность сети АТМ (150 Мбит/с) позволяет передавать немного более 360000 ячеек в секунду, что означает для ATM-переключателя время коммутации менее 2,7 мксек. Реальный переключатель может иметь от 16 до 1024 входных линий, что может означать коммутацию 16-1024 ячеек каждые 2,7 мксек. При быстродействии 622 Мбит/с новая порция ячеек поступает каждые 700 нсек. Постоянство длины ячеек упрощает конструкцию ключа. Все АТМ-ключи имеют целью обеспечить коммутацию с минимальной вероятностью потери и исключить возможность изменения порядка следования ячеек. Приемлемой считается вероятность потери ячейки не более 10-12. Это эквивалентно для большого коммутатора потери 1-2 ячеек в час. Уменьшению вероятности потери способствует создание буферов конвейерного типа. Если на вход переключателя приходят две ячейки одновременно, одна из них обслуживается, а вторая ставится в очередь (запоминается в буфере). Выбор ячеек может производиться псевдослучайно или циклически. При этом не должно возникать предпочтений для каких-то каналов. Если в один цикл на вход (каналы 1, 2, 3 и 4) коммутатора пришли четыре ячейки, предназначенные для выходных линий J+2, J, J+2 и J+1, соответственно, то на линии J+2 возникает конфликт. Предположим, что будет обслужена ячейка, поступившая по первой входной линии, а ячейка на входной линии 3 будет поставлена в очередь. В начале следующего цикла на выход попадут три ячейки. Предположим также, что в этот цикл на ходы коммутатора (1 и 3) придут ячейки адресованные для линий J+3 и J, соответственно. Ячейка, адресованная J, будет поставлена в очередь вслед за ячейкой, адресованной J+2. Все эти ячейки будут переданы только на 4-ом цикле. Таким образом, попадание в очередь на входе ячейки блокирует передачу последующих ячеек даже если выходные каналы для их передачи свободны. Чтобы исключить блокировку такого рода можно организовать очередь не на входе, а на выходе коммутатора. При этом для коммутатора с 1024 входами теоретически может понадобиться 1024 буфера на каждом выходе. Реально число таких буферов значительно меньше. Такая схема АТМ-коммутатора (8*8) показана на рис. 4.3.5.21.
Рис. 4.3.5.21. Схема переключателя с организацией очередей на выходе
Концентратор выбирает N ячеек для помещения в очередь (предполагается, что максимальная длина очереди может быть равна N). Выходной буфер уже заполнен, ячека может быть потеряна. При построении АТМ-коммутаторов часто используется схема
сети с многокаскадными соединениями.
Протоколы сетей X
4.3.2 Протоколы сетей X.25
Семенов Ю.А. (ГНЦ ИТЭФ)
В 1976 году был принят стандарт X.25, который стал основой всемирной системы PSPDN (Packet-Switched Public Data Networks), базирующейся на 7-уровневой модели ISO OSI. Стандарт X.25 был усовершенствован в 1984. X.25 - протокол (ISO 8208:1989; RFC-887, -1381, -1382, -1461, -1598, -1613), который определяет синхронный интерфейс между терминальным оборудованием (DTE - Data Terminal Equipment) и оборудованием передачи данных (DCE - Data Communication Equipment) для терминалов, работающих в пакетном режиме. По существу это протокол связи оборудования с сетью. Главный недостаток протокола X.25 - большие задержки отклика (типовое значение 0.6 сек). Терминалом может служить ЭВМ или любая другая система, удовлетворяющая требованиям X.25. Соединение DTE - DTE осуществляется через DCE. В протоколе X.25 DCE и DTE используют статистическое мультиплексирование с делением по времени. Одновременно могут реализовываться несколько обменных процессов. Схема взаимодействия DTE и DCE выглядит как:
DTE - - DCE - DCE - - DTE
Асинхронный старт-стопный терминал подключается к сети коммутации пакетов через пакетный адаптер данных ПАД (PAD - packet assemble/disassemble) и отвечает рекомендациям X.3, X.28 и X.29. Один ПАД обеспечивает интерфейс для 8, 16 или 24 асинхронных терминалов. Пакет данных состоит обычно из 128 байтов, которые передаются по адресу, содержащемуся в пакете. Но длина пакета может лежать в пределах 64-4096 байтов. Размер пакета также как и величина окна (число пакетов, принимаемых без подтверждения) определяются на фазе установления канала. Прежде чем пакет будет передан, необходимо установить связь между исходными ЭВМ/ПАД и адресуемыми ЭВМ/ПАД. Существуют два вида соединений: коммутируемый виртуальный канал (SVC) и постоянный виртуальный канал (PVC). Предусмотрены две процедуры доступа к каналу:
Процедура доступа к каналу (LAP - link access procedure), в основе которой лежат симметричные операции режима асинхронного ответа (ARM - asynchronous response mode) протокола HDLC.Балансная процедура доступа к каналу (LAPB - link access procedure balanced) на основе асинхронного балансного режима (ABM - asynchronous balanced mode) протокола HDLC. Сетевой уровень реализуется с использованием 14 различных типов пакетов.
Виртуальный канал описывается в общем формате пакета, как "логический канал". Логический канал имеет идентификатор, состоящий из 12 бит. Этот идентификатор обычно состоит из номера группы (4 бита) и номера логического канала (8 бит). В группе может быть до 256 логических каналов (за исключением группы 0, которая может иметь только 255 логических каналов). Возможное число групп - 16, поэтому теоретически возможное число виртуальных каналов для каждого соединения x.25 равно 4095 (16x256-1).
Постоянный виртуальный канал (PVC - permanent virtual circuit) является аналогом выделенного канала.
Коммутируемый виртуальный канал (SVC - switched virtual circuit - напоминает традиционный телефонный вызов) реализует обмен данными. Имеются три типа коммутируемых виртуальных каналов, работающие в дуплексном режиме, но отличающиеся направлением устанавливаемых соединений: входящий SVC, двунаправленный SVC и выходящий SVC. Адресат каждого пакета распознается с помощью идентификатора логического канала (LCI) или номера логического канала (LCN).
SVC используются только на время соединения и становятся доступными для повторного использования после разъединения. Все типы пакетов, за исключением пакетов запроса повторного пуска, содержат идентификатор логического канала. Пакет запрос соединения в SVC является единственным типом пакетов, которые содержат адреса в соответствии с рекомендацией X.121.
Для установки выходящего соединения через svc ЭВМ выбирает логический канал с наибольшим номером в группе и посылает пакет запрос соединения, содержащий выбранный номер группы канала, адрес получателя (в соответствии с рекомендацией X.121) и в отдельных случаях свой собственный адрес. При установлении входящего соединения центр коммутации пакетов (ЦКП) выбирает свободный логический канал с наименьшим номером в группе каналов порта адресуемой ЭВМ и помещает этот логический номер группы и канала в пакет входящий запрос соединения. После того как соединение через svc установлено, ЭВМ направляют свои пакеты, используя номера своих логических групп/каналов, а ЦПК в сети осуществляет транспортировку пакетов и преобразование номеров логических групп/каналов. Как только установленное по svc логическое соединение разъединяется, номера логических групп/каналов на обоих концах соединения освобождаются и становятся доступными для повторного использования. Соответствие между ЦКП/портом, выделенным для терминального оборудования, адресами (согласно рекомендациям x.121) и номерами логических каналов известно в сети только ЦКП.
Выбор ЭВМ свободного канала с наибольшим номером при каждом выходящем соединении и выбор в ЦКП свободного канала с наименьшим номером для каждого входящего позволяют избежать конфликтов. С этой же целью используются две логические группы: одна только для входящих соединений, а другая только для выходящих. Перед подключением к сети пользователь должен определить, сколько pvc и svc требуется на каждую точку физического интерфейса x.25. Асинхронные терминалы подключаются к сети коммутации пакетов через встроенные или удаленные пакетные адаптеры данных (ПАД).
Встроенный ПАД обычно располагается вместе с ЦКП в его стойке. В этом случае каждый асинхронный терминал, расположенный в удаленном месте, подключается к своему встроенному ПАД через отдельный канал связи (протокол Х.28). В альтернативном случае удаленный ПАД (небольшое отдельное устройство) может быть расположен в удаленном месте и подключается к своему ЦКП через канал связи (X.25). С помощью удаленного ПАД к ЦКП подключается 8-16 асинхронных терминалов.
Встроенный ПАД может быть совместно использован несколькими терминалами, расположенными в различных местах, в то время как удаленный ПАД обслуживает терминалы, расположенные обычно в одном месте. Существует еще один аспект размещения ПАД, связанный с помехами в каналах связи и использованием протоколов. Удаленный ПАД подключается к ЦКП на канальном уровне в соответствии с рекомендацией X.25. В качестве протокола канала данных в рекомендации X.25 реализуется подмножество HDLC, обеспечивающее автоматическую повторную передачу данных в случае их искажения при возникновении помех в линии. Асинхронный терминал использует для диалога с групповым ПАД процедуры, описанные в рекомендации X.28, в которых не предусмотрена возможность повторной передачи в случае ошибки. Поэтому канал между синхронным терминалом и групповым ПАД не защищен от возникновения ошибок данных в результате линейных помех. Процедуры ПАД определены в рекомендациях МККТТ (см. приложение 10.1).
Рекомендация X.3: "Пакетный адаптер данных (ПАД) в сети передачи данных общего пользования".
Рекомендация X.28: "Интерфейс между терминальным оборудованием и оборудованием передачи данных (DCE) для старт- стопного оконечного оборудования, осуществляющего доступ к пакетному адаптеру данных в сетях общего пользования".
Рекомендация X.29: "Процедуры обмена управляющей информацией между терминальным оборудованием пакетного типа и пакетным адаптером (ПАД)".
Основные функции ПАД соответствуют рекомендациям X.3:
сборка символов (полученных от асинхронных терминалов) в пакеты;
разборка полей данных в пакетах и вывод данных на асинхронные терминалы;
управление процедурами установления виртуального соединения и разъединения, сброса и прерывания;
обеспечение механизма продвижения пакетов при наличии соответствующих условий, таких как заполнение пакета, получение символа (сигнала) на передачу пакета, истечение времени ожидания;
передача символов, включающих стартстопные сигналы и биты проверки на четность, по требованию подключенного асинхронного терминала;
обнаружение сигнала разрыв соединения от асинхронного терминала;
редактирование последовательностей команд ПАД.
В постоянном запоминающем устройстве ПАД хранятся параметры. Эти параметры могут быть установлены либо асинхронным терминалом, подключенным к ПАД, либо любой ЭВМ в сети, которая удовлетворяет условиям рекомендации X.29. В рекомендации X.29 МККТТ эти параметры названы управляющей информацией. Поэтому необходимо квалифицировать данные, проходящие между ЭВМ и ПАД, либо как управляющую информацию (сообщения ПАД), либо как собственно данные от асинхронного терминала.
Сеть X.25 предоставляет пользователю старт-стопного терминала средства, позволяющие выбрать параметры ПАД с заранее определенными значениями. Пользователь посылает в ПАД команду выбора профайла, которая включает идентификатор профайла. Этим определяется один из нескольких стандартных профайлов, хранящихся в ПАД.
Идентификатор профайла и параметр 11 ПАД (скорость терминала) включаются в "поле данных пользователя" пакетов типа запрос соединения, посылаемых ПАД. ЭВМ (ПАД) использует это поле, извлекая из него информацию о терминале, пославшем запрос.
Пакетный терминал является интеллектуальным устройством (например, ЭВМ, или внешним ПАД’ом), которое обеспечивает синхронный обмен с сетью на скорости 2400, 4800, 9600 бит/c или 48 Кбит/с, используя трехуровневый протокол X.25. Возможная схема подключения терминальных устройств к сети X.25 показана на рис. 4.3.2.1.
Из рисунка 4.3.2.1 видно, что подключение ЭВМ и другого терминального оборудования возможно как к встроенному, так и удаленному ПАД (протокол X.28), а также непосредственно к ЦКП (протокол X.25, X.29). Связи с удаленными объектами осуществляются через соответствующие модемы (на рисунке не показаны).
Для международного соединения необходимо указать код страны из трех цифр, а также набрать одну цифру 9 перед сетевым адресом пользователя. Таким образом, всего требуется не более 15 цифровых символов. Для установления коммутируемого соединения оператор вначале вручную набирает номер ПАД и ждет подтверждения соединения с телефонным узлом общего пользования. Как только соединение установлено, оператор набирает 12-символьный код "сетевого идентификатора пользователя". ПАД обеспечивает операцию эхо-контроля, которая позволяет оператору терминала визуально проверять данные, посылаемые в ПАД. Наиболее серьезным недостатком встроенного ПАД является отсутствие какого-либо линейного протокола, предусматривающего устранение ошибок в данных, посылаемых от ПАД к терминалу. В удаленном ПАД предусмотрена процедура восстановления ошибочных данных, однако он подключается к сети как "пакетный терминал".
Рис. 4.3.2.1. Возможная топология сети X.25
Сетевой адрес пользователя состоит из 12 десятичных цифр. 1-4 - идентификатор сети передачи данных (3 - страна, 4 - сеть); 5-12 - национальный номер (5-7 местная область, 8-12 - местный номер). Международная система адресации для систем передачи данных общего пользователя описана в рекомендациях X.121 международного комитета по телефонии и телеграфии. Каждое подключение к сети коммутации пакетов имеет свой национальный номер. Протокол X.25 не определяет технику маршрутизации пакетов по сети. Для целей управления в сетях X.25 используется протокол snmp и база данных MIB (как и в сетях Интернет). Три базовых уровня протокола X.25 и схема потоков информации отображены на рис. 4.3.2.2.
Для подключения по виртуальному каналу ЭВМ/ПАД посылается пакет (call request), содержащий сетевой адрес пользователя. После подтверждения соединения и передачи/приема данных виртуальное соединение может быть разорвано путем передачи пакета (clear request), инициатором в этом случае выступает удаленная ЭВМ. При невозможности установить связь clear request посылается сетью. Такой пакет содержит два информационных октета. Первый содержит код причины, второй является диагностическим кодом. Ниже в таблице 4.3.2.1 приведены коды причин ошибки.
Таблица 4.3.2.1. Коды причины ошибки
| Код причины | Причина |
| 0x0 | Удаленный сброс (remote cleared) |
| 0x1 | Адресат занят (number busy) |
| 0x3 | Нелегальный запрос (invalid facility request) |
| 0x5 | Перегрузка сети (network congestion) |
| 0x9 | Нарушен порядок (out of order) |
| 0x11 | Ошибка при выполнении удаленной процедуры |
| 0xb | Доступ блокирован (access barred) |
| 0xd | Не доступно, нет в наличии (not obtainable) |
| 0x21 | Несовместимость у адресата (ошибка при выполнении удаленной процедуры) |
| 0x23 | Ошибка при выполнении местной процедуры |
| 0x29 | Сигнал быстрой выборки не воспринят (fast select not accepted) |
Один физический канал связи X.25 может поддерживать несколько коммутируемых виртуальных каналов. Постоянный виртуальный канал подобен выделенной линии - обмен возможен в любой момент. X.25 определяет первые три уровня соединения открытых систем (см. рис. 4.3.2.2).
- физический x.21 (X.21bis)
- канальный (HDLC - high data link communication - протокол высокого уровня управления каналом). Этот уровень и последующие реализуются программным образом.
- сетевой (пакетный)
X.21 - универсальный интерфейс между оконечным оборудованием (DTE) и аппаратурой передачи данных (DCE) для синхронного режима работы в сетях общего пользования. X.21bis – тоже, но для модемов, удовлетворяющих рекомендациям серии V. Для канального уровня используется подмножество протокола HDLC (являющегося развитием стандарта SDLC IBM), обеспечивающее возможность автоматической повторной передачи в случае возникновения ошибок в линии.
Рис. 4.3.2.2. Три уровня X.25
Формат кадра для протокола HDLC показан на рис. 4.3.2.3 (байты передаются, начиная с младшего бита):
Рис. 4.3.2.3. Формат кадра X.25
Открывающий и закрывающий флаги для бит-ориентированного формата несут в себе код 0x7e. Когда не передается никакой информации, по каналу пересылается непрерывный поток флагов 01111110. Посылка более 6 единиц подряд воспринимается как флаг абортирования связи. Если необходимо передать информационную последовательность 01111110, после первых пяти единиц вводится дополнительный нуль, приемник восстанавливает истинную информацию, удаляя эти лишние нули. В случае байт-ориентированных кадров открывающий и завершающий флаги имеют по два байта [DLE (Символы кодов стандарта ISO 646-1973 (МТК-5, ГОСТ 13059-74). Здесь и далее используется русская терминология в соответствии со стандартом ГОСТ 26556-85, STX и DLE, ETX, соответственно, для информационного кадра и DLE, STX и DLE, ETX для управляющего]. Адрес в пакете X.25 занимает всего один байт, что определяет предельное число терминальных устройств, подключаемых к одному каналу. Кадр на уровне 2 имеет двухбайтовый заголовок, содержащий байт адреса и байт типа. Для нумерации кадров на уровне 2 используется 3 бита. При работе со скользящим окном откликов это позволяет иметь до 7 кадров в очереди. При использовании спутниковых каналов с большими задержками можно переходить в режим расширенной нумерации (7 бит), где длина очереди может достигать 128. Если удаленный партнер не способен работать в режиме расширенной нумерации, он отклонит запрос соединения. При работе в режиме расширенной нумерации возможно применение 3-байтовых заголовков вместо двухбайтовых.
Значения поля идентификатора общего формата (GFI - general format identifier) приведено в таблице 4.3.2.2. Бит 8 этого поля (Q) используется в информационных пакетах как индикатор уровня передаваемых данных. Групповой номер логического канала и номер логического канала присваиваются по соглашению с администрацией сети во время постановки на обслуживание. Поля групповой номер логического канала и номер логического канала присутствуют во всех пакетах кроме пакетов регистрации и повторного пуска, где они принимают нулевое значение.
Таблица 4.3.2.2. Значения кодов идентификатора общего формата (GFI)
Тип пакета |
Модуль нумерации |
Номера битов |
|||
8 |
7 |
6 |
5 |
||
Установка соединения |
8 |
0 |
x |
0 |
1 |
|
Разрыв соединения, управление потоком, повторный пуск, регистрация, диагностика |
8 |
0 |
0 |
0 |
1 |
Данные |
8 |
x |
x |
0 |
1 |
Расширение |
- |
0 |
0 |
1 |
1 |
x - бит может принимать значения 0 или 1.
Допустимые значения кодов в поле тип пакета приведены в таблице 4.3.2.3.
Таблица 4.3.2.3. Значения кодов тип пакета
Тип пакета |
Октет 3 |
Биты |
8 7 6 5 4 3 2 1 |
| Запрос | 0 0 0 0 1 0 1 1 |
| Запрос принят | 0 0 0 0 1 1 1 1 |
| Запрос завершения | 0 0 0 1 0 0 1 1 |
| Подтверждение завершения | 0 0 0 1 0 1 1 1 |
| Данные | x x x x x x x 0 |
| Прерывание | 0 0 1 0 0 0 1 1 |
| Подтверждение прерывания | 0 0 1 0 0 1 1 1 |
| Готовность к приему по модулю 8 (RR) | x x x 0 0 0 0 1 |
| Готовность к приему по модулю 128 (RR) | 0 0 0 0 0 0 0 1 |
| Неготовность к приему по модулю 8 (RNR) | x x x 0 0 1 0 1 |
| Неготовность к приему по модулю 128 (RNR) | 0 0 0 0 0 1 0 1 |
|
Запрос повторной установки |
0 0 0 1 1 0 1 1 |
| Подтверждение повторной установки | 0 0 0 1 1 1 1 1 |
| Запрос повторного пуска | 1 1 1 1 1 0 1 1 |
| Подтверждение повторного пуска | 1 1 1 1 1 1 1 1 |
| Диагностика | 1 1 1 1 0 0 0 1 |
| Запрос регистрации | 1 1 1 1 0 0 1 1 |
| Подтверждение регистрации | 1 1 1 1 0 1 1 1 |
x - отмечет разряды, которые могут принимать значения 0 или 1.
Четырехбитовые поля длина адреса отправителя и длина адреса получателя характеризуют длины последующих полей переменной длины. Длина выражается в полуоктетах. Далее следуют соответствующие адреса. В каждом полуоктете записывается десятичная цифра адреса, при необходимости поле адреса дополняется нулями до целого числа октетов. Для пакетов установления связи кадры имеют формат, показанный на рис. 4.3.2.4.
Рис. 4.3.2.4. Формат кадра запроса на соединение и соединение установлено
Поле опции содержит целое число октетов, но не более 109, следующее же поле может содержать до 128 байт. Опция типа fast select позволяет поместить до 64 байтов в информационном поле пользователя, во многих случаях этого оказывается достаточно и исключается необходимость переходить в режим пересылки данных.
Если вызываемое DTE не присылает сообщения вызов принят или запрос завершения (установление связи отвергнуто) за отведенное для этого время, процедура завершается и процессу, инициализировавшему запрос, присылается соответствующий код ошибки. При успешной обработке запроса (прислано сообщение соединение установлено) система переходит в режим обмена данными. DTE может в любой момент инициировать процедуру разрыва связи, послав сообщение запрос завершения. DCE сообщает о завершении соединения путем присылки пакета индикация завершения, на который DTE должно прислать отклик подтверждение завершения. Формат пакетов запроса и подтверждения завершения отображен на рис. 4.3.2.4. и 4.3.2.5. Байты 1 и 2 на рисунке 4.3.2.5 не показаны, так как они идентичны тому, что представлено на рис. 4.3.2.4.
Рис. 4.3.2.5. Формат пакетов запроса завершения
Коды причины завершения связи приведены в таблице 4.3.2.1. Однобайтовое поле диагностический код позволяет уточнить причину. В таблице 4.3.2.4 приведены коды причины повторного пуска. Формат пакетов подтверждения завершения представлен на рис. 4.3.2.6.
Таблица 4.3.2.4. Коды причин повторного пуска
Код причины |
Причина повторного пуска |
0x1 |
Ошибка локальной процедуры |
0x3 |
Перегрузка сети |
0x7 |
Сеть работоспособна |
Рис. 4.3.2.6. Формат пакетов подтверждения завершения
Для инициализации обмена информацией (первичного или повторного), а также для прерывания виртуальной связи и возвращения виртуальных каналов в исходное состояние используются запросы повторного пуска (и подтверждение повторного пуска). DTE может выдать запрос повторного пуска (к DCE) в любой момент времени, переводя логический канал в исходное состояние. DCE в ответ должно послать сообщение подтверждение повторного пуска. Инициатором повторного пуска может быть и dce, для этого оно посылает сообщение индикация повторного пуска. DTE в результате устанавливает логический канал в исходное состояние и посылает dce сообщение подтверждение повторного пуска. Форматы пакетов, несущих эти сообщения показаны на рис. 4.3.2.6 и 4.3.2.7. Эти пакеты не имеют полей группового номера логического канала и LCN (см. рис. 4.3.2.7 и .8). Процедура повторной установки во многом аналогична повторному пуску и используются всякий раз при выявлении сбоя, чтобы вернуть виртуальную связь или постоянный виртуальный канал в исходное состояние.
Рис. 4.3.2.7. Формат пакета запроса повторного пуска (слева) и повторной установки
Таблица 4.3.2.5. Коды причин повторной установки
| Причина повторной установки | Код причины |
| Установка по инициативе dte | 0x0 |
| Повреждение постоянного виртуального канала | 0x1 |
| Ошибка при исполнении удаленной процедуры | 0x3 |
| Ошибка при выполнении локальной процедуры | 0x5 |
| Перегрузка сети | 0x7 |
| Удаленное DTE работоспособно (постоянный виртуальный канал) | 0x9 |
| Сеть работоспособна (постоянный виртуальный канал) | 0xf |
| Несовместимость партнеров | 0x11 |
Партнер - получатель этого запроса должен прислать сообщение подтверждение повторной установки (рис. 4.3.2.8). При этом возможны потери информации (также как и в случае повторного пуска), так как некоторые пакеты, находящиеся в сети в момент реализации запроса повторной установки или повторного пуска будут потеряны.
Инициатором посылки запроса повторной установки может быть dte и dce. Коды причин повторной установки представлены в таблице 4.3.2.5.
Рис. 4.3.2.8. Формат пакета подтверждения повторного пуска (слева) и повторной установки (справа)
Пакеты данных передаются по постоянным виртуальным каналам или через виртуальные соединения после их создания. Пакеты данных распознаются по нулевому младшему биту (бит с номером 1) в третьем октете. Остальные биты этого октета используются для управления. Форматы пакетов данных показаны на рис. 4.3.2.9.
Информационное поле начинается с четвертого байта (при расширенной нумерации с пятого) и может иметь длину 16-4096, хотя в рекомендациях стандарта x.25 оговорена величина 128 октетов. Если принимающая сторона не способна принять пакет данной длины, связь должна быть переустановлена, а стороне-инициатору соединения послано сообщение об ошибке. Каждому пакету данные присваивается порядковый номер N(S), значение которого при установлении соединения равно нулю.
Рис. 4.3.2.9. Форматы пакетов данные. Слева - по модулю 8, справа - по модулю 128
Q -бит определяет тип кадра-пакета, Q=1 - управляющий пакет для PAD, Q=0 - информационный пакет. Бит D используется для запроса специального отклика на пакет со стороны удаленного конца виртуального канала. Бит M указывает на то, что данный пакет является частью более крупного пакета, который должен быть воссоздан позднее.
Индекс S (send) соответствует отправке, а индекс R - приему (receive). Если используется нумерация пакетов по модулю 8, N(S) занимает биты 2-4 включительно, при нумерации по модулю 128 для этого отводятся биты 2-8. Нумерация пакетов позволяет выявить потерю пакетов или изменение порядка их доставки. N(R) является номером пакета с принимающей стороны. Бит подтверждения доставки D (идентификатор формата) служит для указания необходимости сообщения о доставке данных получателем. Если D=1, то DTE обязано подтвердить доставку. Обязательность процедуры подтверждения определяется уже на фазе установления связи (сообщение запрос на установление связи принят). Если какой-либо узел по пути пересылки пакета не поддерживает процедуру подтверждения доставки, он пошлет сообщение запрос завершения (причина - несовместимость у адресата) и связь должна быть сформирована заново с учетом необходимости подтверждения во всех узлах-участниках. Размер поля данные в пакете может быть разным для разных узлов, участвующих в обмене. По этой причине число полученных пакетов может оказаться больше (или меньше) числа посланных. Для таких случаев предусмотрен флаг m (дополнительные данные). Возможность фрагментации и последующей сборки пакетов определяется управляющими битами M и D (см. таблицу 4.3.2.6).
Таблица 4.3.2.6. Управление фрагментацией и сборкой пакетов с помощью битов M и D
Бит m |
Бит d |
Выполнение объединения с последующим пакетом (реализуется сетью) |
0 |
0 |
Нет |
0 |
1 |
Нет |
1 |
0 |
Да |
1 |
1 |
Нет |
Таким образом, при фрагментации исходного сообщения все пакеты кроме последнего должны иметь бит m=1. Нумерация пакетов по модулю 8 означает, что им последовательно присваиваются номера 0,1,2,3,4,5,6,7,0,1,2 и т.д. Аналогично при нумерации по модулю 128 - 0,1,2,...127,0,1,2,3 и т.д. Форма нумерации пакетов определяет также размер “окна”, то есть число пакетов, которые могут быть переданы, не дожидаюсь подтверждения получения. По умолчанию размер окна равен 2, другие значения могут быть согласованы на фазе установления соединения. Принцип использования окон при передаче пакетов более подробно описан в разделе “3.6.2
Протокол TCP”.
Для управления процессом передачи данных используются сообщения “готов к приему” и “не готов к приему”. Форматы этих пакетов показаны на рис. 4.3.2.10 и 4.3.2.11.
Рис 4.3.2.10. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 8.
Рис 4.3.2.11. Формат пакетов готовность к приему и неготовность к приему при нумерации по модулю 128.
Код N(R) на входе DCE должен лежать в пределах между N(R) последнего принятого пакета и N(S) следующего пакета, который должен быть послан из DCE к DTE. При невыполнении этого условия связь будет переустановлена и передача повторена. Пакеты готовность к приему используются для сообщения о готовности принять пакеты, с номерами, начиная с номера N(R), приведенного в пакете. Пакеты неготовность к приему служат для того, чтобы сообщить о временной неспособности принять данные. При поступлении этого сообщения отправитель должен прервать передачу до получения сообщения готовность к приему. DTE может передавать данные удаленному DTE, не следуя правилам управления потоком данных. Для реализации такой возможности предусмотрена операция прерывания. Эта операция не влияет на передачу данных и управление. Формат пакета прерывание и подтверждение прерывания показан на рис. 4.3.2.12.
Рис. 4.3.2.12. Формат пакетов прерывание и подтверждение прерывания
Идентификатор формата равен 0x1 для нумерации по модулю 8 и 0x2 при нумерации по модулю 128. Передав сообщение прерывание, DTE должно ожидать получение пакета подтверждение прерывания. Максимальный размер поля данные пользователя в пакете прерывание не должен превышать 32 байт.
Иногда в сетях для сообщения об ошибке используется пакет “диагностика”. Этот пакет посылается DCE, адресуется DTE и несет информацию о неустранимых на уровне пакетов ошибках. Пакет диагностика посылается лишь один раз сразу после выявления ошибки. Подтверждения его получения не требуется. Формат пакета показан на рис. 4.3.2.13.
Рис. 4.3.2.13. Формат пакета диагностика
Поле код диагностики несет в себе информацию об ошибке, вызвавшей посылку этого пакета. Если же пакет диагностика передается в качестве отклика на пакет с ошибками от DTE, то поле уточнение диагностики содержит первые три байта пакета DTE.
Современные сети создаются ради доступа к определенным услугам. В протоколе X.25 предусмотрена процедура, которая позволяет получить текущие значения параметров услуг (опций) и модифицировать их. Эта процедура называется регистрацией и не является обязательной. Форматы пакетов запроса регистрации и подтверждения регистрации показаны на рис. 4.3.2.14 и 4.3.2.15. Максимальный размер поля регистрация составляет 109 байт. Инициатором регистрации всегда является dte, которое передает запрос регистрации. В качестве отклика dce посылает пакет подтверждение регистрации, в котором содержатся информация о параметрах доступных услуг. Для выявления доступных услуг может быть послан запрос регистрации, не содержащий списка запрашиваемых услуг.
Рис. 4.3.2.14. Формат пакетов запрос регистрации
Рис. 4.3.2.15. Формат пакетов подтверждение регистрации
Получив список доступных услуг из сообщения подтверждение регистрации, может поменять параметры некоторых из них. Если значение какого-либо параметра услуги (опции) не разрешено, DCE должно сообщить разрешенное значение параметра и максимальное и или минимальное разрешенное значение (в зависимости от того больше или меньше допустимого оказалось значение запрошенного параметра).
Неисправность сети может привести к тому, что та или иная согласованная ранее услуга станет недоступной. В этом случае DCE должно инициировать процедуру повторного пуска, чтобы уведомить DTE о случившихся изменениях.
Кроме процедуры регистрации к необязательным процедурам относятся услуги для замкнутой группы, идентификация пользователей сети, группа поиска, ускоренный обмен, переадресация вызовов, выбор транзитной сети, сообщения о модифицированном адресе, согласование параметров управления потоком и некоторые другие.
Повторная передача пакетов согласуется на определенное время и может использоваться во всех логических каналах DTE-DCE. DTE запрашивает повторную передачу одного или нескольких пакетов данные путем посылки сообщения отказ reject), которое определяет логический канал и порядковый номер пакета N(R). Получив пакет отказ DCE, DTE начинает повторную передачу пакетов. Формат пакетов отказ для случаев нумерации по модулю 8 и 128 показан на рис. 4.3.2.16.
Рис. 4.3.2.16. Форматы пакетов типа отказ для нумерации по модулю 8 (слева) и 128
Программное обеспечение принимающей и передающей сторон должно иметь переменные состояния V(R) и V(S), содержащие, соответственно, номера пакетов, которые предстоит получить и послать (см. описание процедуры HDLC). После посылки очередного пакета с N(S) значение V(S) увеличивается на 1. Принимающая сторона сравнивает V(R) с N(S) полученного пакета, при совпадении укладывает N(S) в поле N(R) пакета-отклика и инкрементирует V(R). Отправитель при получении пакета проверяет равенство переменной V(S) и кода поля N(R) в пакете-отклике. Если при получении пакета выясняется, что V(R) не равно N(S), V(R) не инкрементируется, а принимающая сторона отправляет отклик с N(R)=V(R). Отправитель, получив этот отклик и обнаружив, что V(S) не равно N(R), узнает о происшедшем сбое. Номер логического канала (LCN) служит для того, чтобы определить соответствие межу DTE и местным DCE. LCN вместе с полем группового номера логического канала занимают 12 бит, что позволяет иметь до 4095 логических каналов (LCN=0 зарезервировано для использования DCE).
4 бита первого байта управляющего пакета содержат в себе код типа сообщения (таблица 4.3.2.7):
Таблица 4.3.2.7 Коды типов сообщений
Код типа сообщения |
Команда PAD |
Отправитель |
0001 |
Команда разъединения |
ЭВМ |
0010 |
Установление параметров |
ЭВМ |
0011 |
Индикация разъединения |
ЭВМ или PAD |
0100 |
Чтение параметров |
ЭВМ |
0101 |
Ошибка |
PAD |
0110 |
Установка и чтение параметров |
ЭВМ |
В поле управляющего сообщения PAD может быть включено любое число параметров, которое допускает максимальный размер пакета. Каждый параметр имеет свой код-номер, за которым в пакете следует значение параметра (таблица 4.3.2.8):
Таблица 4.3.2.8. Коды параметров PAD
Код параметра |
Описание |
1 |
Обращение к ПАД с использованием управляющего символа |
2 |
Эхо-контроль |
3 |
Выбор сигнала посылки пакета |
4 |
Выбор продолжительности ожидания для таймера |
5 |
Управление вспомогательным устройством |
6 |
Подавление управляющих сигналов ПАД |
7 |
Выбор действий ПАД при получении сигнала разрыва |
8 |
Прерывание вывода |
9 |
Кодовая последовательность после сигнала "возврат каретки" |
10 |
Перенос строки, длина которой ограничена размерами экрана дисплея |
11 |
Скорость работы старт-стопного терминала |
12 |
Управление потоком ПАД |
13 |
Вставка символа "перевод строки" после символа "возврат каретки" |
14 |
Заполнение после сигнала "перевод строки" |
15 |
Редактирование |
16 |
Стирание символа |
17 |
Стирание строки |
18 |
Вывод строки на экран дисплея |
19 |
Редактирование сигналов управления ПАД |
20 |
Маскирование эхо-контроля |
21 |
Обработка символов контроля на четность |
22 |
Ожидание страницы |
При работе TCP/IP сети через каналы X.25 и наоборот следует учитывать некоторые отличия кодов предпочтения в полях TOS. Таблица 4.3.2.9 содержит соответствие этих кодов для этих сетей.
Таблица 4.3.2.9. Соответствие кодов TOS для сетей TCP/IP и X.25
IP |
X.25 |
IP |
X.25 |
000 |
00 |
001 |
01 |
|
010 |
10 |
011 - 111 |
11 |
Для реализации работы сетей ISDN по существующим каналам сети X.25 разработан протокол X.31. X.31 организует канал пользователь-маршрутизатор X.25 (через посредство ISDN) и регламентирует работу ISDN с пакетами X.25.
Для решения первой задачи используется сообщение SETUP. Вторая задача решается, когда канал до маршрутизатора сформирован. На этом этапе привлекается набор протоколов X.25, возможно применение протокола X.75 (ISO 8208), который является расширением X.25 для межсетевых связей.
Работа с сервером новостей
4.5.7.1 Работа с сервером новостей
Семенов Ю.А. (ГНЦ ИТЭФ)
Основные группы новостей, рассылаемые по всему миру, это: alt, comp, misc, news, rec, sci, soc и talk. Существует много других базовых категорий новостей, например, bionet, biz, vmsnet, которые рассылаются также повсеместно или в рамках какого-то региона или организации (например, ieee), а также коммерческие (например, clari). Последние категории рассылаются только ограниченно. Сообщения многих Bitnet LISTSERV серверов также рассылаются в виде новостей и относятся к категории bit.
Наиболее важные группы новостей:
Тематика
Базовые категории разбиваются на более чем 1200 групп новостей по различным вопросам и темам (от образования для инвалидов до Star Trek и от науки об окружающей среде до политики в странах бывшего Советского Союза). Качество дискуссий в этой среде не гарантируется. Некоторые группы имеют посредников, которые просматривают сообщения перед рассылкой. Usenet была разработана в 1979 году для системы UNIX. В настоящее время в сети новостей работает несколько тысяч узлов, охватывающих практически весь земной шар.
Новости доступны как через локальный сервер, так и через телефонные коммутируемые сети. Программы для поддержки локального сервера новостей доступны в Интернет, UUCP, EARN/Bitnet и Fidonet. Если вам доступна только электронная почта, тогда для вас Usenet не доступна. Однако, многие группы новостей подключены к спискам почтовой рассылки и вы можете подписаться на них. Для этого шлите запрос в LISTSERV@AMERICAN.EDU со строкой: GET NETGATE GATELIST. Более того, многие документы, которые появляются в новостях, доступны по электронной почте в mail-server@rtfm.mit.edu. Для получения руководства по применению в поле subject напишите HELP.
Команды (базовые), используемые при выборе групп новостей
Основные команды
| h | Отобразить справочную информацию; |
| q | quit rn (чтение новостей) - прерывание чтения новостей; |
| x | quit rn, изменения, внесенные в ваш файл .newsrc, не будут сохранены; |
| v | Показать, c какой версией rn вы работаете. RN – прикладная программа, предназначенная для просмотра новостей. |
| Space | Выполнение команды по умолчанию; |
| y | Чтение текущей группы новостей; |
| - | Тоже самое, что и y, но отображает список тем (subjects); |
| ^N | Переход к следующей нечитанной статье по тому же вопросу; |
| k | Пометить как читанные все статьи по текущей теме (subject). |
| = | Выдать список всех нечитанных статей; |
| число | Переход к статье с данным номером; |
| # | Отобразить номер последней статьи. |
| n | Переход к следующей группе новостей с нечитанными статьями; |
| p | Переход к предшествующей группе с нечитанными статьями; |
| P | Назад к следующей статье читанной или не читанной; |
| ^P | Назад к предыдущей статье по той же теме; |
| ^ | Переход к первой группе новостей с нечитанными статьями; |
| ^R | Заново вывести на экран текущую статью; |
| $ | Переход в конец списка групп новостей; |
| g группа новостей | Переход к заданной группе новостей; |
| /эталон | Поиск в прямом направлении группы, содержащей эталон; |
| ? эталон | Поиск в обратном направлении группы, содержащей эталон; |
| / | Поиск в прямом направлении предшествующего эталона; |
| G | Повторить поиск с направлением вперед; |
| ? | Поиск в обратном направлении предшествующего эталона; |
| u | Ликвидация подписки на текущую группу новостей; |
| v | Заново вывести на экран текущую статью вместе с заголовком; |
| l эталон | Выдача списка неподписанных групп, содержащих эталон; |
| L | Выдача состояния групп новостей в файле .newsrc; |
| ^L | Заново вывести на экран текущую страницу; |
| b | Возврат назад на одну страницу; |
| c | Пометить все новости в группе как прочитанные; |
| A | Пренебречь всеми изменениями в данной группе новостей; |
| j | Пометить статью, как прочитанную и перейти в конец; |
| ^X | Декодировать текущую статью, используя ROT-13; |
| X | Декодировать текущую страницу, используя ROT-13; |
/p> Отклик на статью
| r | Послать отклик автору статьи по электронной почте; |
| R | То же, что и r, но в ответ включается исходный текст; |
| f | Запуск программы Pnews для написания статьи отклика; |
| F | То же, что и f, но с включением текста исходной статьи. |
| s файл | Запись статьи в файл; |
| w файл | То же, что и s, но без записи заголовка. |
| ! команда | Выполнить данную Unix-команду; |
| ! | Прервать исполнение rn и уйти в Shell. |
Существует поддержка Usenet в самых разных операционных системах: Unix, VMS, MS-DOS, OS/2, Macintosh, MVS, а также в различных средах: MS-Windows, X-Windows, Windows-NT, Emacs. Имеются интерфейсы для системы USENET и для электронной почты. Многие, реально почти все, программные продукты обеспечивают следующие возможности:
Подписка на группы новостей. Это означает, что именно новости данной группы будут немедленно доступны и вы сможете их просмотреть, когда пожелаете.
Аннулирование подписки на группы новостей. Группа удаляется из вашего списка.
Чтение оглавления групп новостей. Ваш локальный сервер выдает вам оглавление новостей и отслеживает, какие из них вы уже читали.
Нить дискуссии. Вы можете отслеживать оглавления групп новостей, имеющих отношение к одной и той же теме или предмету.
Посылка сообщения в группу новостей. Вы можете участвовать в дискуссии, ваш сервер новостей знает, куда послать ваше сообщение.
Отклик на сообщение. Вы можете послать отклик на любое сообщение (это часто называется follow-up [отклик]) или обратиться к автору сообщения (это обычно называется replay [ответ]).
Выбрав с помощью стрелки группу новостей и нажав клавишу <Enter>, вы получите оглавление статей в группе. Символ "+" указывает на то, что не все сообщения в цепочке были прочитаны. После выбора конкретной статьи вам будет предоставлено ее содержание.
Когда вы введете TIN (программа просмотра новостей), вы получите список групп новостей, на которые вы подписались:
tin 1.2 PL2 [UNIX] (c) Copyright 1991-93 Iain Lea.
(загрузка просмотрщика новостей)
Reading news active file...
Reading attributes file...
Reading newsgroups file... h=help
| Group | Selection (3658) | (выдается базовое меню групп новостей) |
| 1 | 26 | alt.0d | |
| 2 | 72 | alt.1d ? | |
| 3 | 50426 | alt.2600 | |
| 4 | 79 | alt.3d | Dis |
| 5 | 496 | alt.abortion.inequity | Pat |
| 6 | 83 | alt.abuse.recovery | ? |
| 7 | 41087 | alt.activism | Act |
| 8 | 231 | alt.activism.d | A p |
| 9 | 106 | alt.activism.death-penalty | |
| 10 | 208 | alt.adoption | Ado |
| 11 | 37 | alt.aeffle.und.pferdle | Ger |
| 12 | 40 | alt.agriculture.fruit | ? |
| 13 | 26 | alt.agriculture.misc | Gen |
| 14 | 8 | alt.aldus.freehand | ? |
| 15 | 5 | alt.aldus.misc | ? |
| 16 | 78 | alt.aldus.pagemaker | ? |
| <n>=set current to n, | TAB=next unread, | /=search pattern, | c)atchup, | g)oto, |
| j=line down, | k=line up, | h)elp, | m)ove, | q)uit, |
| r=toggle all/unread, | s)ubscribe, | S)ub pattern, | u)nsubscribe, | U)nsub |
| pattern, | y)ank in/out |
Goto newsgroup [comp.mail.misc]> comp.inforsystems.gopher
( получаем новое меню, выбранная тема помечена стрелкой на левом поле)
Group Selection (3658)
| 1825 | 189 comp.graphics.animation Tec | |
| 1826 | 26 comp.graphics.visualization Inf | |
| 1827 | 19 comp.groupware Har | |
| 1828 | 180 comp.groupware.lotus-notes.misc | |
| 1829 | 151 comp.home.automation | |
| 1830 | comp.home.misc | |
| 1831 | 53 comp.human-factors Iss | |
| 1832 | 27 comp.infosystems Any | |
| 1833 | comp.infosystems.announce | |
| 1834 | 130 comp.infosystems.gis All | |
| --> | 1835 | 8 comp.infosystems.gopher Dis |
| 1836 | 1 comp.infosystems.interpedia | |
| 1837 | comp.infosystems.kiosks | |
| 1838 | 27 comp.infosystems.wais The | |
| 1839 | 302 comp.infosystems.www.misc | |
| 1840 | 16 comp.internet.library Dis |
| 1 | + 3 mime-type Wolfgang Zekoll | |
| 2 | + Harmony Binary Release 1.1 Mansuet Gaisbauer | |
| 3 | + IRD Internet Gopher sites file Fritz Bohnet | |
| --> | 4 | + telnet via gopher Monty FullerDC |
| 5 | + WWW shop of British fine tea from Williamson webmaster@sswi.com | |
| 6 | + WWW shop of Billy Riggs' sermon tapes webmaster@sswi.com |
Does anyone have a list of sights through which one can access telnet by way of gopher? Thanks for any help. Sincerely, Monty Fuller
Посмотрим следующее сообщение (пункт 5):
Hi,
I would like to invite everybody to visit our WWW shop of British fine tea from Williamson & Magor: Assam, Celebration Blend, Darjeeling, Earl Grey, English Breakfast, Lifeboat.
Go to http://www.sswi.com/, and look under "Shopping Mall": Have a nice holiday. Web Master
http://www.sswi.com/ (может быть интересно для любителей хорошего чая).
В документе 3 найдем полезную информацию об адресе, где лежит список Gopher-серверов:
I have found the IRD Gopher sites file to be a very useful tool for searching the Internet. For those of you who want to have a look, here is the download site:
http://www.mbmarktcons.com/mbmarkt/irdhome.htm
or via FTP from:
ftp://ftp.mbmarktcons.com/pub/mbmarkt/ird/Fritz
Вернувшись назад в предыдущее меню и выбрав позицию 1838 (comp.infosystems.wais), мы получим другой список документов:
comp.infosystems.wais (19T 26A 0K 0H R)
| 1 | + searching for an underscore ("_") Thomas Carter |
| 2 | + Multi-field search w/freeWAIS-sf Paul Bingman |
| 3 | + 2 Help, compiling FreeWAIS under Sun OS 4.1.4 Adrian Blakey |
| 4 | + Harmony Binary Release 1.1 Mansuet Gaisbauer |
| 5 | + 2 freewais-sf BIO patches? Tak |
| 6 | + Indiceing single letters with freeWAIS-sf-2.0 B. D.O.Adams |
| 7 | + Wais database and html page question? Hans Baartmans |
| 8 | + Help on Virtual Warehousing Daniel Chang |
| 9 | + Question on freeWAIS and SFgate Anna Lee |
| 10 | + 2 Combining numeric fields in boolean search Frances Blomeley |
| 11 | + 2 Indexing PDF files Robert M. Ioffe |
| 12 | + extending length of filenames in freewais-sf Brenda Levesque |
| 13 | + Question: Timestamp problem with wais? Hans Baartmans |
| 14 | + 3 sockets.c – make errors Jason Wilkes |
| 15 | + freewais, wais, and Solaris Philippe Cuif |
| 16 | + 2 freeWAIS-sf Can't compile on BSD Jack Ellis |
Серверы новостей взаимодействуют друг с другом согласно стандартным протоколам, некоторые из которых описаны в Internet RFC. В настоящее время в этом списке имеются:
RFC-977 описывает NNTP (Network News Transfer Protocol)
RFC-1036 определяет формат статей Usenet.
Некоторые группы новостей содержат статьи и дискуссионные материалы по использованию Usenet. Например: news.announce.newusers, news.answers и news.newusers.questions. Многие статьи, которые появляются в этих группах новостей доступны также с помощью анонимного FTP по адресу rtfm.mit.edu или по электронной почте по адресу: mail-server@rtfm.mit.edu.
Разъем AUI
10.16 Разъем AUI
Семенов Ю.А. (ГНЦ ИТЭФ)
Номер контакта
Название
Назначение
Разводка разъемов
10.17 Разводка разъемов
Семенов Ю.А. (ГНЦ ИТЭФ)
RJ-11
(6 контактов)
Телефонный разъем
Применение неэкранированных скрученных пар
| Использование | Ножки разъема | ||||||||
| 1-2 | 3-6 | 4-5 | 7-8 | ||||||
| Аналоговая передача голоса | - | - | TR/RX | - | |||||
| 10BASE-T | TX | RX | - | - | |||||
| 100BASE-TX | TX | RX | - | - | |||||
| 100BASE-T4 | TX | RX | - | - | |||||
| 100BASE-VG | BI | BI | BI | BI | |||||
| ISDN | Питание | TX | RX | Питание | |||||
| Token Ring | - | TX | RX | - | |||||
| ATM-пользователь | TX | RX | |||||||
| ATM-разветвитель | RX | TX |
TX – передача; RX – прием; BI – двунаправленная передача/прием.
Интерфейс RS-530
| Разводка разъема интерфейса RS-232 | |||||
| Номер контакта | Сторона ЭВМ (DTE) Разъем DB25M | Устройство передачи данных (DCE) Разъем DB25F | |||
| 1 | Экран | Экран | |||
| 2 | Выход передачи данных (TD) | Вход приема данных (RD) | |||
| 3 | Вход приема данных (RD) | Выход передачи данных (TD) | |||
| 4 | Запрос передачи данных (RTS) | Запрос приема данных (CTS) | |||
| 5 | Запрос приема данных (CTS) | Запрос передачи данных (RTS) | |||
| 6 | Вход готовности (DSR) | Выход готовности (DTR) | |||
| 7 | Земля сигнала | Земля сигнала | |||
| 8 | Вход CD (Carrier Detect) | Выход CD (Carrier Detect) | |||
| 20 | DTE готов (DTR) | DCE готов (DSR) | |||
| 22 | Индикатор вызова (RI) | Индикатор вызова (RI) |
Интерфейс V.24/RS-232 (9-контактный)
Интерфейс V.35
Интерфейс X.21
Интерфейс V.36/RS-449
Региональные сети
4.3 Региональные сети
Семенов Ю.А. (ГНЦ ИТЭФ)
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 4.3 | Региональные сети | 1 |
5 |
| 4.3.1 | Эталонная сетевая модель ISO | 5 |
68 |
| 4.3.2 | Протоколы сетей X.25 | 18 |
213 |
| 4.3.3 | Интегрированные сети ISDN | 25 |
451 |
| 4.3.4 | Протокол Frame Relay | 6 |
77 |
| 4.3.5 | Протоколы сетей ATM | 21 |
254 |
| 4.3.6 | Синхронные каналы SDH/SONET | 9 |
165 |
| 4.3.7 | Модемы | 10 |
126 |
Региональные сети (WAN - Wide Area Network) с точки зрения архитектуры и протоколов практически не отличаются от глобальных. В региональных сетях обычно не используются трансокеанские кабели, но это отличие не может рассматриваться как принципиальное. Региональные сети решают проблему формирования из LAN (локальных сетей) сетей регионов и целых стран и даже наднациональных сетей (например, E-BONE для Европы). Как правило, эти сети строятся с использованием протоколов SDH, ATM, ISDN, Frame Relay или X.25. Архитектурно такие сети формируются из каналов со схемой точка-точка и мощных коммутаторов-мультиплексоров. Из таких фрагментов формируются и опорные сети (BackBone), которые позволяют сократить число шагов от узла к узлу. В этих сетях в основном используются оптоволоконные транспортные системы, а там где это нерентабельно, спутниковые или радиорелейные каналы.
С появлением корпоративных сетей типа Интранет понятия локальной и региональной сетей стало частично перекрываться. Для пользователя Интранет все узлы такой сети являются локальными, хотя и могут отстоять на сотни или даже тысячи километров друг от друга. По существу сети Интранет являются наложенными сетями по отношению к региональным сетям (WAN). Интернет также следует отнести к числу наложенных сетей по отношению к WAN.
Рекомендации CCITT по телекоммуникациям
10.1 Рекомендации CCITT по телекоммуникациям
Семенов Ю.А. (ГНЦ ИТЭФ)
E
G
H
I
Q
T
V
X
|
Код рекомендации |
Содержание |
||
| ANSI T1.102 | Цифровая иерархия - электрические интерфейсы; | ||
| ANSI T1.111-116 | Сигнальная система N7; | ||
| ANSI T1.403 | Конструкция интерфейса DS1 | ||
| ANSI T1.408 | Спецификация связи пользователя с первым уровнем первичного канала; | ||
| ANSI T1.602 | Интерфейс базового канала, процедура доступа к первичному каналу, D-канал (LAP1); связной протокол BRI/PRI; | ||
| ANSI T1.603 | Минимальный набор услуг для интерфейса первичного канала ISDN; | ||
| ANSI T1.604 | Минимальный набор услуг базового канального интерфейса ISDN; | ||
| ANSI T1.605 | Спецификация интерфейса базового канала для связи пользователя с сетью; спецификация интерфейса BRA S/T; | ||
| ANSI T1.606 | Описание услуг Frame Relay; | ||
| ANSI T1.607 | Основные управляющие процедуры для BRI и PRI; | ||
| ANSI T1.608 | Пакетные режимы канала. Управляющие процедуры BRI и PRI; | ||
| ANSI T1.609 | Цифровая система подписки N1 ISDN для межсетевых связей в рамках сигнальной системы N7; | ||
| ANSI T1.610 | Базовые процедуры для управления вспомогательными услугами ISDN; | ||
| ANSI T1.617 | Сигнальные спецификации для канальных услуг Frame Relay; | ||
| ANSI T1.618 | Базовые аспекты протокола Frame Relay; | ||
| CCIR 601-1 | Параметры кодировки студийного цифрового телевидения; | ||
| ECMA-104 | Физический уровень интерфейса для доступа к первичному каналу в частных телекоммуникационных сетях; | ||
| ECMA-105 | Протокол уровня канала данных для D-канала интерфейса в эталонной точке между терминальным оборудованием и частной телекоммуникационной сетью; | ||
| ECMA-106 | Протокол третьего уровня для управления переадресацией вызовов через интерфейс D-канала в эталонной точке S между терминальным оборудованием и частной телекоммуникационной сетью | ||
| ECMA-123 | Обмен параметрами в частных ISDN-сетях на базе стандарта ECMA-102; | ||
| ECMA-133 | Эталонная конфигурация для вызовов через коммутатор частной телекоммуникационной сети; | ||
| ECMA-134 | Метод спецификации базовых и дополнительных видов сервиса в частных телекоммуникационных сетях. | ||
| ECMA-135 | Алгоритмы связи коммутаторов частных телекоммуникационных сетей; | ||
| ECMA-141 | Протокол уровня канала данных для эталонной точки Q сигнального канала между коммутаторами частных телекоммуникационных сетей; | ||
| ECMA-142 | Влияние спецификации, функциональной модели и потоков данных на управление базовыми услугами в частных телекоммуникационных сетях; | ||
| ECMA-143 | Протокол третьего уровня для управления переадресацией вызовов между коммутаторами частных телекоммуникационных сетей; | ||
| ECMA148 | Идентификация дополнительных услуг в частных телекоммуникационных сетях; спецификация, функциональные модели и информационные потоки; | ||
| ECMA-155 | Адресация в частных телекоммуникационных сетях; | ||
| ECMA-156 | Основные процедуры для управления дополнительными услугами, используя протокол keypad в эталонной точке S. | ||
| ECMA-157 | Протокол управления по D-каналу в эталонной точке S интерфейсами между терминальным оборудованием и частной телекоммуникационной сетью для поддержки идентификации дополнительных услуг. | ||
| F.60 | Стандарт телексной связи | ||
| F.69 | Стандарт для телексных адресов | ||
| F.160 | Стандарт на международную общественную факсную связь | ||
| F.200 | Стандарт телетекстной связи | ||
| F.201 | Стандарт для служб межсетевого обмена для телетекста и телекса | ||
| F.300 | Набор рекомендаций для систем видеотекста | ||
| F.401 | Стандарт на имена и адреса при передаче сообщений | ||
| F.410 | Стандарт службы передачи сообщений | ||
| F.420 | Стандарт для частного обмена сообщениями | ||
| F.421 | Стандарт для коммуникаций между системами X.400 для обмена частными и телексными сообщениями | ||
| F.500 | Стандарт международной службы каталогов | ||
| G.702 | Иерархия цифровых скоростей обмена | ||
| G.703 | Физические и электрические характеристики цифровых интерфейсов. | ||
| G.707 | Иерархия частот синхронной передачи двоичной цифровой информации | ||
| G.708 | Синхронный интерфейс сетевого узла для цифровой передачи данных в широком диапазоне частот следования. | ||
| G.709 | Структура синхронного мультиплексирования. | ||
| G.711 | Импульсно-кодовая модуляция (PCM) голосовых частот. | ||
| G.721 | Адаптивная дифференциальная кодово-импульсная модуляция (ADPCM) для частоты 32 Кбит/с. | ||
| G.722 | Аудио кодирование в частотном диапазоне 7 кГц для скоростей передачи 64 Кбит/с. | ||
| G.725 | Системные аспекты использования 7 килогерцного аудио кодека на скоростях передачи 64 Кбит/с. | ||
| G.728 | CCITT рекомендация для ADPCM при16 Кбит/с (3.1 кГц) | ||
| H.221 | Структура кадра канала на 64 Кбит/с для аудио и видео приложений. | ||
| H.231 | Многоточечный контроль для скоростей 64-2048 Кбит/с | ||
| H.242 | Коммуникационные процедуры, 64-2048 Кбит/с. | ||
| H.243 | Многоточечные коммуникационные процедуры, 64-2048 Кбит/с. | ||
| H.261 | Видео кодек для аудио-видео сервиса при p*64 Кбит/с (p=1-30). | ||
| H.320 | CCITT рекомендации для узкополосных видео-телефонных систем и терминального оборудования со скоростями не более 1920 Кбит/с. Общее описание CODEC. | ||
| I.110 | Введение и общая структура серии документов “I” для интегрированных цифровых сетей ISDN | ||
| I.111 | Взаимоотношения с другими рекомендациями, относящимися к ISDN | ||
| I.112 | Словарь терминов ISDN | ||
| I.113 | Словарь терминов для широкополосной ISDN | ||
| I.120 | Интегрированные цифровые сети ISDN | ||
| I.121 | Широкополосные аспекты ISDN | ||
| I.122 | Рамки для предоставления услуг в канале, работающем в пакетном режиме | ||
| I.130 | Метод описания телекоммуникационных услуг, поддерживаемых ISDN и сетевые возможности ISDN | ||
| I.140 | Методика атрибутов для описания телекоммуникационных услуг ISDN сетевых возможностей ISDN | ||
| I.141 | Атрибуты сети ISDN | ||
| I.150 | Характеристики ATM B-ISDN | ||
| I.200 | Указатель по серии рекомендаций I.200 | ||
| I.210 | Принципы предоставления телекоммуникационных услуг ISDN и методы их описания | ||
| I.211 | Аспекты услуг B-ISDN | ||
| I.220 | Общее динамическое описание базовых телекоммуникационных услуг | ||
| I.221 | Общие характеристики услуг | ||
| I.327 | Функциональная архитектура сетей B-ISDN. | ||
| I.230 | Определение категорий услуг, предоставляемых каналом | ||
|
Коммутация каналов |
|||
| I.231 | Категории схемных услуг, предоставляемых каналом | ||
| I.231.1 | 64 Кбит/с (структура по 8кбит/с) | ||
| I.231.2 | 64 Кбит/с (структура по 8кбит/с) с возможностью передачи звуковой информации | ||
| I.231.3 | 64 Кбит/с (структура по 8кбит/с) для аудио-передачи с полосой 3.1 кГц | ||
| I.231.4 | 64 Кбит/с (структура по 8кбит/с) попеременный разговор | ||
| I.231.5 | 2* 64 Кбит/с (структура по 8кбит/с) | ||
| I.231.6 | 384 Кбит/с (структура по 8кбит/с) | ||
| I.231.7 | 1536 Кбит/с (структура по 8кбит/с) | ||
| I.231.8 | 1090 Кбит/с (структура по 8кбит/с) | ||
|
Коммутация пакетов |
|||
| I.232 | Категории пакетных услуг, предоставляемых каналом | ||
| I.232.1 | Виртуальный вызов и постоянная виртуальная схема | ||
| I.232.2 | Бессвязная схема | ||
| I.232.3 | Пользовательская сигнальная система | ||
| I.233.1 | Услуги передачи кадров (frame relay) в ISDN - передача кадров | ||
| I.233.2 | Услуги передачи кадров (frame relay) в ISDN - коммутация кадров | ||
| I.240 | Определение удаленных услуг | ||
| I.241 | Удаленные услуги, поддерживаемые ISDN | ||
| I.250 | Определение дополнительных услуг | ||
| I.251 | Идентификационные коды вспомогательных услуг | ||
| I.252 | Запрос вспомогательных услуг | ||
| I.253 | Завершение выполнения вспомогательных услуг | ||
| I.253.1 | Ожидание запроса вспомогательных услуг | ||
| I.254 | Вспомогательные услуги для нескольких клиентов | ||
| I.255.4 | Приоритетное обслуживание | ||
| I.257 | Передача дополнительной информации | ||
| I.310 | Принципы работы сети ISDN | ||
| I.311 | Общие аспекты сети B-ISDN | ||
| I.312(Q.1201) | Принципы архитектуры интеллектуальных сетей | ||
| I.320 | Эталонная модель протоколов ISDN | ||
| I.321 | Эталонная модель протоколов B-ISDN и ее применение | ||
| I.324 | Архитектура сети ISDN | ||
| I.325 | Типы эталонных конфигураций соединений в ISDN | ||
| I.326 | Относительные требования к ресурсам сети | ||
| I.327 | Функциональная архитектура сети B-ISDN | ||
| I.328 (Q.1202) | Интеллектуальная сеть - архитектура плоскости услуг | ||
| I.329 (Q.1203) | Интеллектуальная сеть - архитектура глобальных функций | ||
| I.330 | Принципы нумерации и адресации в ISDN | ||
| I.331 (E.164) | Схема нумерации в ISDN | ||
| I.332 | Принципы нумерации для межсетевых соединений ISDN и сетей с различными схемами нумерации | ||
| I.333 | Выбор терминала в ISDN | ||
| I.334 | Принципы связи чисел/субадресов ISDN и сетевых адресов эталонной модели OSI | ||
| I.335 | Принципы маршрутизации ISDN | ||
| I.351 (G.821/2) | Рекомендации других серий, связанные c работой сети, для эталонной точки T ISDN | ||
| I.352 | Объективные характеристики сети, связанные с задержками соединений в ISDN | ||
| I.361 | Спецификация слоя ATM B-ISDN | ||
| I.362 | Функциональное описание адаптационного уровня для B-ISDN (AAL). | ||
| I.363 | Спецификация уровня адаптации (AAL) ATM B-ISDN | ||
| I.370 | Управление перегрузкой для каналов фрейм-релей ISDN | ||
| I.410 | Общие аспекты и принципы, связанные с рекомендациями для пользовательского интерфейса ISDN | ||
| I.411 | Сетевой интерфейс пользователя ISDN - эталонная конфигурация | ||
| I.412 | Интерфейс пользователя сети ISDN - структура интерфейса возможности доступа | ||
| I.413 | Интерфейс пользовательской сети B-ISDN | ||
| I.420 | Базовый сетевой интерфейс пользователя | ||
| I.421 | Сетевой интерфейс пользователя первичного быстродействия | ||
| I.430 | Базовый сетевой интерфейс пользователя - спецификация слоя 1 | ||
| I.431 | Сетевой интерфейс пользователя первичного быстродействия - спецификация уровня 1 | ||
| I.432 | Сетевой интерфейс пользователя B-ISDN - спецификация физического уровня | ||
| I.440 (Q.920) | Связной информационный уровень сетевого интерфейса пользователя ISDN общие аспекты | ||
| I.441 (Q.921) | Сетевой интерфейс пользователя ISDN - спецификация связного информационного уровня | ||
| I.450 (Q.930) | Сетевой интерфейс пользователя ISDN - уровень 3, общие аспекты | ||
| I.451 (Q.931) | Спецификация уровня 3 для сетевого интерфейса пользователя ISDN для управления базовыми запросами | ||
| I.452 (Q.932) | Общие процедуры для управления дополнительными услугами ISDN | ||
| I.460 | Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов | ||
| I.461 (X.30) | Поддержка терминального оборудования (DTE) базирующегося на X.21, X.21бис и X.20бис интегрированными цифровыми сетями (ISDN) | ||
| I.462 (X.31) | Базовые процедуры для управления дополнительными услугами ISDN | ||
| I.463 (V.110) | Поддержка ISDN терминального оборудования в пакетном режиме | ||
| I.464 | Мультиплексирование, адаптация к скорости передачи и поддержка существующих интерфейсов для передачи на скоростях 64 Кбит/с | ||
| I.465 (V.120) | Поддержка ISDN терминального оборудования с интерфейсами типа V при статистическом мультиплексировании | ||
| I.470 | Взаимодействие терминальных функций и ISDN | ||
| I.500 | Общая структура рекомендаций для взаимодействия ISDN | ||
| I.510 | Определения и общие принципы взаимодействия в ISDN | ||
| I.511 | Интерфейс уровня 1 для системы ISDN-ISDN | ||
| I.515 | Обмен параметрами при взаимодействии систем ISDN | ||
| I.520 | Общие принципы организации для межсетевых взаимодействий в ISDN | ||
| I.530 | Взаимодействие сетей ISDN и публичных коммутируемых телефонных сетей | ||
| I.540 (X.321) | Общие приспособления для взаимодействия между сетями ISDN и коммутируемыми публичными телефонными сетями (CSPDN) | ||
| I.550 (X.325) | Общие приспособления для взаимодействия между сетями ISDN и публичными сетями с пакетным переключением (PSPDN) для целей передачи информации | ||
| I.560 (U.202) | Требования, предъявляемые к системе ISDN для обеспечения телексных услуг | ||
| I.601 | Общие принципы работы системы доступа для клиента ISDN и инсталляция клиента | ||
| I.602 | Использование принципов ISDN при инсталляции клиентов | ||
| I.603 | Использование принципов работы ISDN для обеспечения доступа | ||
| I.604 | Использование принципов работы ISDN для обеспечения доступа на первичных скоростях обмена | ||
| I.605 | Применение принципов статического мультиплексирования при реализации базового доступа к ISDN | ||
| I.610 | OAM-принципы доступа в B-ISDN | ||
| ISO 2110 | Передача данных 25-контактный соединитель интерфейса DTE-DCE и распределение его контактов. | ||
| ISO 2593 | Распределение контактов разъема для высокоскоростного терминального оборудования. | ||
| ISO 3166 | Коды стран (DCC - Data Country Code). | ||
| ISO 4902 | Передача данных. 37- и 9-контактные разъемы интерфейса DTE-DCE и распределение контактов. | ||
| ISO 4903 | Передача данных. 15-контактный разъем интерфейса DTE-DCE и распределение контактов. | ||
| ISO 8473 | Протокол доступа к сети без непосредственной связи (CLNAP ConnectionLess Network Access Protocol) | ||
| ISO 8877 | Интерфейсный разъем и назначение контактов для эталонных точек доступа ISDN S и T. | ||
| ISO 9282-2 | Метод сжатия стационарного изображения | ||
| ISO 11172-3 | Кодировка движущегося изображения и сопровождающего звука для цифровых систем записи при скоростях передачи 1,5 Мбит/с - Часть 3. Звук. | ||
| Q.500 | Введение и область применения ISDN | ||
| Q.512 | Интерфейс коммутатора для доступа клиентов ISDN | ||
| Q.513 | Интерфейс коммутатора для операций, администрирования и обслуживания | ||
| Q.521 | Функции интерфейса | ||
| Q.522 | Цифровой коммутатор. Связи, управление, вспомогательные функции | ||
| Q.541 | Общая конструкция | ||
| Q.542 | Конструкция, операции и обслуживание | ||
| Q.543 | Рабочие характеристики систем ISDN | ||
| Q.544 | Измерения на коммутаторе ISDN | ||
| Q.551 | Передающие характеристики цифровых коммутаторов | ||
| Q.552 | Передающие характеристики 2-х проводных аналоговых интерфейсов | ||
| Q.553 | Передающие характеристики 4-х проводных аналоговых интерфейсов | ||
| Q.554 | Передающие характеристики цифровых интерфейсов | ||
| Q.700-795 | Спецификация сигнальной системы N7. | ||
| Q.920 | Интерфейс пользователя в сети ISDN, общие аспекты связного уровня. | ||
| Q.921 | Интерфейс пользователя в сети ISDN, спецификация связного уровня. | ||
| Q.922 | Спецификация ISDN связного уровня для пакетной передачи данных. | ||
| Q.930 | Интерфейс пользователя в сети ISDN, слой 3, общие принципы. | ||
| Q.931 | Интерфейс пользователя в сети ISDN, спецификация слоя 3, базовые процедуры управления. | ||
| Q.932 | Базовые операции управления дополнительными процедурами в ISDN. | ||
| Q.933 | Цифровая сигнальная подписная система N1 (DSS1), сигнальные модификации для режима передачи кадров | ||
| T.4 | Стандарт на факсимильное оборудование группы 3 для передачи документации. | ||
| T.6 | Схемы кодирования изображения и кодирование функций управления для факсимильного оборудования группы 3. | ||
| T.81 | Кодирование фотографического изображения. | ||
| T.411-418 | Открытая архитектура документации (ODA) | ||
| T.431-433 | Манипуляция документами и протокол передачи DTAM. | ||
| T.503 | Профайл BTO для передачи факсимильных документов группы 4. | ||
| T.521 | Коммуникационный профайл BTO для пересылки документов большого объема, базирующейся на методике сессий. | ||
| T.563 | Терминальные характеристики факсимильного оборудования группы 4. | ||
| V.24 | Перечень определений цепей связи DTE и DCE (для DTE, работающих с модемами). Этой спецификации соответствуют RS-232-C, RS-449-A. | ||
| V.28 | Электрические характеристики несимметричных цепей интерфейса, работающего с биполярными токовыми сигналами. | ||
| X.3 | Спецификация ПАД для общественных сетей (X.25) | ||
| X.20 | DTE-DCE интерфейс старт-стопной передачи данных по сетям общего пользования | ||
| X.21 | DTE-DCE интерфейс для синхронной передачи данных по сетям общего пользования. Определяет физические характеристики и процедуры управления. | ||
| X.21бис | Использование DTE, рассчитанного на сопряжение с синхронными модемами, удовлетворяющими рекомендациям серии V в сетях обмена данными общего пользования | ||
| X.22 | Мультиплексный интерфейс DTE-DCE для классов обслуживания абонентов 3-6; | ||
| X.24 | Перечень определений цепей интерфейса DTE-DCE. Определяет функции цепей передачи данных, управления и синхронизации. | ||
| X.25 | Протокол пакетного уровня для интерфейса DTE-DCE и терминалов, подключенных к общественным сетям. | ||
| X.26 | Электрические характеристики несимметричных двухполюсных цепей, предназначенных для общего использования в устройствах передачи данных (V.10). | ||
| X.27 | Электрические характеристики симметричных цепей, предназначенных для устройств передачи информации с сетях общего пользования (V.11). | ||
| X.28 | Интерфейс DTE-DCE для старт-стопного режима работы терминального оборудования, работающего в общественных сетях с использованием ПАД. | ||
| X.29 | Процедуры обмена управляющей информацией и данными между ПАД и DTE или другим ПАД (пакетный ассемблер-дизассемблер). | ||
| X.31 | Поддержка терминального оборудования, работающего в пакетном режиме (ISDN). | ||
| X.32 | Интерфейс DTE-DCE для терминалов, работающих в пакетном режиме и связанных с коммутируемой телефонной сетью общего пользования. | ||
| X.75 | Терминальные управляющие процедуры и системы передачи данных для международных межсетевых обменов. | ||
| X.121 | Схема нумерации для общественных информационных сетей | ||
| X.150 | Испытательные шлейфы DTE и DCE для сетей обмена данными общего пользования. | ||
| X.200 | Эталонная модель соединения открытых систем для приложений. | ||
| X.208 | CCITT-версия OSI ASN.1 | ||
| X.209 | Версия OSI ASN.1 базовых правил кодирования (BER) | ||
| X.210 | Рекомендации по сервису в открытых системах на связном уровне. | ||
| X.211 | Физическое определение услуг в OSI для CCITT-приложений | ||
| X.212 | Определения услуг информационных каналов в OSI для CCITT-приложений | ||
| X.213 | Определения сетевых услуг для связей между открытыми системами. | ||
| X.214 | Определение транспортных услуг связи открытых систем для приложений CCITT. | ||
| X.215 | Определение сессий для связанных открытых систем. | ||
| X.216 | Описание процедур презентации для связанных открытых систем. | ||
| X.217 | Описание процедуры управления для связанных открытых систем. | ||
| X.218 | CCITT-эквивалент ISO 9066-1: Надежная пересылка текстов | ||
| X.219 | Удаленные операции: модель, нотация и описание услуг. | ||
| X.223 | Использование X.25 для обеспечения сетевой связи в режиме OSI | ||
| X.224 | Спецификация транспортного протокола связи открытых систем для приложений CCITT. | ||
| X.225 | Спецификация протокола сессий для связанных открытых систем. | ||
| X.226 | Протокол презентаций для связанных открытых систем. | ||
| X.227 | Спецификация протокола управления для связанных открытых систем. | ||
| X.228 | Надежная передача данных, спецификация протокола. | ||
| X.229 | Удаленные операции: спецификация протокола. | ||
| X.237 | Определения передачи, одновременности и служб восстановления для связанных открытых систем. | ||
| X.247 | Спецификация передачи, одновременности и служб восстановления для связанных открытых систем. | ||
| X.400 | Система обработки сообщений: системная модель, элементы сервиса. | ||
| X.401 | Система обработки сообщений: базовые элементы сервиса и опционные пользовательские возможности. | ||
| X.402 | Стандарт для пересылки сообщений | ||
| X.403 | CCITT-система работы с сообщениями: Проверка сохранности | ||
| X.407 | Абстрактные описания услуг | ||
| X.408 | Система обработки сообщений: правила преобразования кодированной информации. | ||
| X.409 | Система обработки сообщений: синтаксис и нотация презентационных пересылок. | ||
| X.410 | Система обработки сообщений: удаленные операции и надежный сервер пересылок. | ||
| X.411 | Система обработки сообщений: уровень передачи сообщений. | ||
| X.413 | Запоминание сообщений: абстрактные определения услуг | ||
| X.419 | Спецификации протоколов | ||
| X.420 | Система обработки сообщений: уровень обмена сообщениями между пользователями сети. | ||
| X.430 | Система обработки сообщений: протокол доступа для терминалов телетекста. | ||
| X.500 | Стандарт на каталоги, базирующийся на OSI (RFC 1279, 1275, 1274) | ||
| X.509 | CCITT-каталоги: Система идентификации | ||
| X.511 | Абстрактные описания услуг | ||
| X.519 | Спецификации протоколов | ||
| X.520 | Некоторые типы атрибутов | ||
| X.521 | Для определенных классов объектов | ||
| Z.100-104 | SDL (Specification and Description Language) язык описания и спецификаций |
Серверы подписки (LISTSERV)
4.5.9 Серверы подписки (LISTSERV)
Семенов Ю.А. (ГНЦ ИТЭФ)
Доступ к LISTSERV может получить всякий пользователь, кто может посылать электронные сообщения по адресам EARN/Bitnet (в соответствии со стандартом RFC-822) и имеет пригодный к использованию адрес. Отличие от обычной электронной почты заключается в том, здесь вы можете обратиться не только к тем партнерам, адреса которых вы знаете, но и к тем о существовании которых и не подозреваете. Однажды по работе мне потребовалась информация по ультрафиолетовой дозиметрии, я послал запрос в один из серверов и в течение суток получил 6 ответов из США, Канады и Новой Зеландии (среди них Stephan Straus stephen@unicaat.yorku.ca, Martin Brown brauwnma@ucs.oust.edu). Неизвестные мне доселе люди снабдили меня необходимыми данными, указали адреса, где можно найти дополнительную информацию, прислали списки библиографии. Обратите внимание, чтобы однозначно определить, кого я имею в виду, достаточно указать электронный адрес.
Для того, чтобы наладить контакт с LISTSERV нужно послать запрос по адресу: LISTSERV@host-id, где host-id NJE-адрес ЭВМ (например, TAUNIVM.BITNET) или имя INTERNET-домена (в этом случае, VM.TAU.AC.IL). Серверу LISTSERV можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Возможно взаимодействие с LISTSERV и в интерактивном режиме.
Для облегчения связи с сервером необходимо определить узловую ЭВМ в сети EARN/Bitnet. Пользователи вне сети EARN/Bitnet могут посылать свои запросы по адресу LISTSERV.NET. Заметьте, что если этот узел еще не определен для вашей сети, вы можете попробовать работать на LISTSERV%LISTSERV.BITNET@CUNYVM.CUNY.EDU. Вы можете также использовать специальный LISTSERV-адрес, чтобы послать e-mail в любой LISTSERV-список. Например, если вы хотите послать электронное сообщение в список BITFTP-L для того, чтобы получить копию программы BITFTP, вы можете сделать это, послав сообщение по адресу BITFTP-L@LISTSERV.NET. Ваше сообщение будет автоматически переадресовано по реальному адресу (в данном случае BITFTP-L@EARNCC.BITNET), когда оно попадет в узел LISTSERV. Существует (на конец 1994 года) более 250 узлов в более чем 30 странах мира, где работают серверы LISTSERV. Вот некоторые из них:
Команды имеют следующий формат: заглавные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров. Важными ключевыми словами являются:
PW=пароль - это ключевое слово служит для описания слова-пароля. Если вы завели слово-пароль для данного LISTSERV-сервера, вы должны в дальнейшем записывать в командном тексте строку PW=, чтобы ваши команды были выполнены. Эта функция создана, чтобы блокировать возможность исполнения команд, используя ваш электронный адрес. Если вы зарегистрировали ваш пароль в сервере LISTSERV, вы обязаны включать PW= во все команды, где это требуется по описанию.
F=формат - это ключевое слово управляет форматом файла (или внутренней структурой файла), в котором он будет вам послан. Если вы не являетесь членом EARN/Bitnet, то LISTSERV будет всегда использовать формат MAIL. В противном случае формат файла зависит от информации, которая содержится в BITEARN NODES файле вашей ЭВМ. BITEARN NODES файл - это специальный файл описания сетей, используемый в EARN/Bitnet сетях. Любой пользователь может затребовать формат, отличный от описанного по умолчанию, посредством F=командное_ключевое_слово в командах, где это требуется опционно. Допустимы следующие форматы файлов:
XXE UUe MIME/text MIME/Appl MAIL
Кроме того, пользователи EARN/Bitnet могут задать:
Netdata Card Disk Punch LPunch VMSdump
Первичной задачей LISTSERV является обслуживание списков электронных адресов (списки для рассылки). Эти списки используются, чтобы пересылать сообщения подписчикам. Таким образом, создаются форумы для обмена идеями и информацией по темам, интересующим подписчиков. Пользователю достаточно помнить только один адрес (адрес сервера), чтобы взаимодействовать с большим числом лиц, имеющим сходные интересы. Обсуждения или дебаты при этом могут иметь всемирный характер.
В рамках LISTSERV почтового списка могут использоваться следующие команды, которые служат для поиска нужного списка и адреса соответствующего сервера, для подписки или ее отмены и т.д.
SUBscribe имя_списка <полное_имя>
Эта команда служит для включения подписчика в список для рассылки. Вы можете использовать эту команду для изменения имени (но не электронного адреса), под которым вы уже известны в списке. имя_списка - это наименование списка, на который вы хотите подписаться. Например, EARN User Group список, находящийся в узле IRLEARN, имеет имя EARN-UG. Не следует путать имя списка с адресом сервера (EARN-UG@IRLEARN). Опционный параметр полное_имя позволяет вам выдать имя, под которым вы хотите фигурировать в списке (это может быть псевдоним). При посылке этой команды в LISTSERV по e-mail полное имя будет взято из поля From:. При посылке этой команды в сервер, где вы уже подписаны, это будет воспринято, как требование об изменении полного имени. Запрос о присоединении к подписному листу может быть обработан тремя путями: подписка может быть OPEN, CLOSED или BY-OWNER. Если это OPEN, вы будете автоматически добавлены в список и получите подтверждение этого. Если это CLOSED, вы будете вычеркнуты из списка рассылки. Если вас там не было, вы получите уведомление о том, что запрос не выполнен. Если же это BY-OWNER, ваш запрос будет переадресован собственнику списка, кто и решит добавлять вас к списку или нет. Адрес, куда будет переправлен ваш запрос, вам будет прислан. Для того, чтобы быть исключенным из списка посылайте команду:
UNSubscribe имя_списка | * <(NETWIDE>
Наличие круглой скобки только слева не является опечаткой. Для того, чтобы ликвидировать подписку по всем спискам LISTSERV, можете использовать "*" вместо имени списка. Если вы хотите, чтобы ваш запрос был передан всем серверам сети, используйте команду (NETWIDE. Эта версия команды рекомендуется при смене вашего электронного адреса или при длительном отпуске. Для получения списка имеющихся списков в сервере LISTSERV используйте команду List.
List <option> <F=формат>
Параметр option может принимать следующие значения:
Short
Отображается резюме всех списков, контролируемых LISTSERV, по одной строке на список. Эта версия реализуется по умолчанию;
Long
(детально) пересылает вам файл (называемый node-name LISTS), содержащий исчерпывающие описания всех списков, поддерживаемых сервером.
Global <эталон>
Выдается полный список всех известных почтовых списков LISTSERV на текущий момент. Этот файл имеет имя LISTSERV LISTS и содержит имена, заголовки и e-mail адреса этих списков. Это очень большой файл, поэтому следует проверить, есть ли у вас достаточно места на диске, прежде чем использовать опцию Global. Опционный параметр эталон может использоваться для того, чтобы выбрать имя списка, заголовок или список адресов.
Для получения листинга почтовых списков используется команда REView. Формат команды:
REView имя_списка <(> <option>
Листинг будет вам переслан в виде файла с именем list-name LIST (или list-name node-name). Почтовый список состоит из двух частей: управляющая секция и подписная секция. Управляющая секция содержит параметры списка, которые включают в себя информацию о том, кто решает вопросы включения в список или его пересмотра, а также архивации. Подписная секция содержит e-mail адреса и имена всех членов списка. REView-команда позволяет вам получить листинг любой или обеих этих секций (по умолчанию - обеих) для любого из списков. Следует иметь в виду, что по решению владельца списка командой REView может выдаваться только список членов этого списка. В этом случае вам не будет позволено просматривать список e-mail адресов, если вы не член списка. Члены списка могут ограничить доступ к своему e-mail адресу по команде REView, если они установили опцию CANCEL. имя_списка - имя LISTSERV-списка, который вы хотите просмотреть. К важным опциям команды REView относятся:
Short
Получаемая информация ограничивается управляющей секцией (только параметры списка).
Countries
Выдается перечень членов списка упорядоченный с учетом национальной принадлежности.
LOCal
Если список имеет пару (соединен с другим списком того же имени, обслуживаемым другим сервером), вы получите полный листинг в отклик на команду REView.
Опция LOCal может использоваться для подавления распространения действия команды REView на другие серверы. В этом случае вы получите листинг только от сервера, куда вы послали запрос.
При подключении к какому-либо списку, вам будет поставлен в соответствие перечень параметров по умолчанию. Эти параметры могут быть вами изменены для любого из списков, где вы являетесь подписчиком. Команда Query позволяет просмотреть текущие значения параметров (опций) для любого списка. Формат команды:
Query имя_списка | *
Параметр имя_списка представляет собой наименование списка, на который вы подписались. Если вы используете символ "*" вместо имени списка, вы получите информацию о ваших личных параметрах для всех списков, на которые вы подписаны.
Для изменения параметров вашей подписки используется команда SET. Она имеет формат:
SET имя_списка | * options
После выполнения команды SET сервер пришлет вам подтверждение успешного изменения параметра по электронной почте. Важными опциями команды SET являются:
Mail | DIGests | INDex | NOMail
Эти опции варьируют способ, которым вы получаете сообщения. Mail означает, что вы хотите получать сообщения по электронной почте (значение по умолчанию).
DIGests и INDex доступны только в случае, если они разрешены собственником списка. DIGests сохраняет все сообщения посланные в список в течении определенного времени. Вместо того, чтобы получать сообщения одно за другим вы получите их единым кластером в определенный день недели или месяца. Обратите внимание, DIGests не редактирует почту и вы получите все сообщения. INDex передаст вам только дату, время, предмет, число строк, имя отправителя и адреса всех сообщений, посланных в список. Текст сообщений передан не будет. Вы можете выбрать и извлечь заинтересовавшие вас сообщения. NoMail означает, что вам не будут пересылаться сообщения. Это полезно при длительной командировке или отпуске. Вернувшись, вы можете послать команду SET c опцией Mail и возобновить присылку сообщений. Предусмотрена возможность изменения формата заголовков почтовых сообщений.
SHORThdr | FULLhdr | IETFhdr | DUALhdr
Все почтовые сообщения состоят из секции заголовка и тела сообщения. Заголовок содержит информацию об отправителе, получателе, дате и времени отправки. Перечисленные выше опции команды SET указывают на тип заголовка почтового сообщения, который вы хотите иметь. SHORThdr означает, что заголовок сообщения будет содержать только самую существенную информацию (например, Date:, To:, From:, Subject:, и Replay-to: поля). Этот вариант работает по умолчанию. Вы можете изменить это, используя опцию FULLhdr, которая означает, что все (даже не существенные) поля заголовка будут присутствовать в почтовом сообщении. Опция IETFhdr означает, что LISTSERV не изменит заголовок, за исключением того, что добавит в заголовок Received: (а также Message-id: и Sender:, если их там не было). Эта опция введена для обеспечения совместимости с SMTP. Наконец DUALhdr очень похожа на SHORThdr за исключением того, что LISTSERV введет заголовок в начало тела сообщения. Следовательно, когда сообщение получено и читается получателем с этой опцией, оно начнется с этой информации (например, первые три строки сообщения могут содержать To:. From:, и Subject). Эта опция удобна для таких почтовых пакетов на PC, где эта информация не отображается.
CONCEAL | NOCONCEAL
указывает на то, хотите вы или нет, чтобы ваше имя и почтовый адрес появлялся в ответ на команду REView, выданную одним из подписчиков списка. По умолчанию работает NONCONCEAL. Обратите внимание, что полный список подписчиков доступен владельцу списка и администратору LISTSERV, вне зависимости от установки этой опции.
Для возобновления вашей подписки необходимо выдать команду COMFIRM. Формат команды:
CONFIRM имя_списка
Некоторые подписные листы требуют регулярного подтверждения подписки (обычно раз в год). Система автоматически напоминает пользователям, что они должны подтвердить свою подписку, т.е. они должны послать команду CONFIRM в течение заданного числа дней. В противном случае клиент будет вычеркнут из списка. Эта команда должна быть послана с того же адреса, по которому было послано напоминание. LISTSERV присылает подтверждение получения команды CONFIRM.
LISTSERV может работать также и как файл-сервер. Поэтому сервер может запоминать файлы и обеспечивать к ним доступ по запросам. Эти файлы запоминаются в рамках иерархической системы filelists. Как и предполагает его название filelist представляет собой специальный файл, который содержит список файлов. Каждая запись в filelist описывает файл, который можно затребовать, давая информацию о его имени, размере, а также коде доступа (File Access Code), который описывает, кто имеет доступ к нему. Эти файлы сами могут быть списками файлов. Таким образом, эта файловая система имеет древовидную структуру.
На LISTSERV существует два вида файлов-списков. Первый тип содержит файлы, которые помещены туда специально хозяином списка или его администратором. Это могут быть документы, карты, диаграммы или даже программы. Файлы-списки второго вида ассоциированы со списком адресов LISTSERV. Это списки файлов-списков, они состоят из серии файлов, каждый из которых хранит (обычно до месяца) копию сообщения, которое было ранее разослано. При желании в течение определенного времени эти файлы могут быть скопированы любым подписчиком.
LISTSERV может компоновать один или более файлов в пакет и в таком виде рассылать подписчикам. Это могут быть, например, файлы, необходимые для генерации определенной программы. Пакет декларируется в LISTSERV-filelist через файл, который именуется packet-name $PACKEGE. В нем хранятся описания всех файлов, которые представляют собой пакеты. Любой файл, представляющий собой пакет, может быть извлечен из хранилища с помощью запроса: packet-name PACKAGE. Обратите внимание, что в этом случае символ $ в имени опущен. Таким образом, одна команда позволяет извлечь из депозитария сразу несколько файлов, входящих в пакет.
Некоторые команды позволяют пользователю манипулировать файлами, которые хранятся в депозитарии LISTSERV. Сюда входят команды подписки и извлечения файлов. При посылке команд файл-серверу вы должны адресовать их именно серверу, а не какому-либо почтовому списку.
Используйте команду INDex для получения списка файлов из определенного filelist. Формат команды:
INDex <список_файлов> <F=формат>
Параметр список_файлов определяет имя списка, который вас интересует. Если не указано ни какого имени, вам будет прислан индекс корневого списка файлов (именуемого LISTSERV FILELIST).
Команда GET используется для извлечения какого-то определенного файла или пакета файлов из списка файлов, если вам разрешено это делать. Формат команды:
GET имя_файла тип_файла <список_файлов> <F=формат>
Параметры имя_файла и тип_файла описывают файл или пакет файлов, который вы хотите получить. Параметр список_файлов определяет список файлов или пакетов, где лежит искомый файл. Если этот параметр не указан, LISTSERV будет определять его путем поиска в собственном индексе, что задержит выполнение запроса.
Для подписки на файлы или пакеты из определенного списка следует использовать команду AFD (Automatic File Distribution). Формат команды:
AFD options
Каждый раз, когда данный список или конкретный файл актуализуется (изменяется), вам будет выслана сервером его копия. Число файлов или пакетов, на которые вы подписаны, не лимитировано. Вы можете в любой момент просмотреть перечень подписки и ликвидировать ее частично или полностью. Параметр options команды AFD может принимать одно из следующих значений:
ADD имя_файла тип_файла <список_файлов> <текст>
<F=формат> <PW=password>
Опция ADD позволяет вам подписаться на файл или пакет, имя_файла и тип_файла характеризует при этом имя и тип файла, на который вы подписались. Если вы хотите, чтобы автоматически в начало каждого присылаемого файла или пакета добавлялся некоторый текст, используйте параметр текст. Если вы пропускаете параметр список_файлов, то параметр текст должен быть помещен в кавычки.
DELete filename filetype <filelist> <PW=password>
Эта опция служит для аннулирования подписки, имена могут содержать символы * (wildcard). Опция List показывает файлы или пакеты, на которые вы в данный момент подписаны. Формат опции:
List <(FORMAT>
Если вы включите опцию (FORMAT, то будет отображен и формат, в котором вам будет присылаться файлы или пакеты. Еще одна команда, которая позволяет осуществить подписку на файлы и пакеты, носит название FUI (File Update Information). Ее формат:
FUI options
Эта команда аналогична AFD за исключением того, что вы в данном случае получаете сообщение об изменении файла или пакета, а не его новую копию. Эта команда допускает следующие опции:
ADD имя_файла тип_файла <список_файлов> <PW=пароль>
Аналог ADD для команды AFD за исключением параметров формат и текст. Опция DELete является полным аналогом одноименной опции команды AFD:
Для получения информации об актуализации файлов или пакетов удобна команда Query File. Параметр список_файлов может быть опущен. Формат команды:
Query File имя_файла тип_файла <список_файлов> <(FLags>
Вы можете задать параметр (Flags, который позволит администрации LISTSERV получить дополнительную техническую информацию о файле, полезную при описании проблем, с которыми вы столкнулись.
Команда PW позволяет вам добавить, изменить или ликвидировать ваше персональное слово-пароль. Команда имеет следующий формат:
PW options
Слово-пароль блокирует возможность несанкционированного использования вашего электронного адреса. Настоятельно рекомендуется воспользоваться этой возможностью. Запрос на регистрацию слова-пароля может быть воспринят в любое время, аналогично оно может быть изменено и аннулировано также, когда вы захотите. Слово-пароль может включать в себя от одного до 8 алфавитно-цифровых символов. Среди опций этой команды могут быть:
ADD new-password
Добавляет новое слово-пароль. Если вы зарегистрировали свое слово-пароль, вы обязаны впредь его использовать всюду (вводить командное ключевое слово PW=), где это требуется опционно.
CHange old-password new-password
Изменяет ваше старое слово-пароль на новое.
DELete old-password
Удаляет ваше слово-пароль из сервера, если вы уже имели его. После этого вы уже не обязаны вводить впредь командное ключевое слово PW=.
Функции LISTSERV DATABASE
LISTSERV позволяет пользователям извлекать старые почтовые сообщения, которые рассылались по списку какое-то время назад. Каждый почтовый список имеет ассоциированную базу данных (обычно называемую notebook или база данных list archive), в которую производится запись рассылаемых сообщений. Такая возможность зависит от хозяина списка и присутствует не всегда. Практически каждый сервер имеет базу данных по узловым ЭВМ сети EARN/Bitnet, которая называется BITEARN. Эта база доступна для всех пользователей. Базовые серверы имеют также базы данных по всем узловым ЭВМ LISTSERV (база имеет название PEERS). Для того, чтобы определить, какие базы данных доступны на данном сервере выдайте команду DATABASE LIST. Для выполнения поиска в базе данных вы можете послать e-mail в LISTSERV c соответствующим запросом в базу данных. Кроме того, пользователи EARN/Bitnet на VM или VMS системах имеют интерактивный доступ к базам данных через программу LDBASE. Для получения более детальной информации пошлите команду Info DATABASE на ближайший сервер.
LISTSERV может выдать пользователю много и другой информации: статистика запросов, справочные и конфигурационные файлы и пр. При запросе этой информации следует адресоваться к серверам, а не к какому-либо списку. К числу команд, помогающих извлечь вспомогательную информацию, относится HELP. В ответ на эту команду вы получите по электронной почте описание наиболее употребимых команд LISTSERV, а также имя сервер-почтмейстера и его электронный адрес.
Для получения help-файла из LISTSERV можно выдать команду Info, которая имеет формат:
INFO <тема> <F=формат>
Опция тема должна характеризовать тематику файла, который вы получите в ответ. Если вы пошлете запрос в ближайший (или любой) LISTSERV без указания темы, то получите список возможных тем запросов.
Допустим вы хотите подписаться на список EARNEWS, который находится в узле FRMOP11. Ваше полное имя Yuri A. Semenov. Пошлите следующую команду по адресу LISTSERV@FRMOP11.BITNET:
SUBSCRIBE EARNEWS Yuri A. Semenov
Если вы хотите покинуть INFO- MAC список, где вы были подписчиком ранее, в узле CEARN, выдайте команду:
UNSUBSCRIBE INFO-MAC
которая должна быть послана серверу LISTSERV в CEARN, который управляет списком INFO_MAC. Для того чтобы покинуть все списки LISTSERV, пошлите команду в ближайший сервер LISTSERV:
UNSUBSCRIBE * (NETWIDE
Если вы хотите получить полный список всех списков рассылки, которые в своем названии содержат слово Europe. Пошлите следующую команду ближайшему серверу LISTSERV:
LIST GLOBAL EUROPE
Вы хотите прекратить получение сообщений из всех списков SEARN, где вы состоите подписчиком. Пошлите серверу LISTSERV в SEARN команду:
SET * NOMAIL
Предположим, что вы получили сообщение от сервера LISTSERV в IRLEARN с просьбой подтвердить вашу подписку на список EARN-UG и вы согласны это сделать. Пошлите серверу команду:
CONFIRM EARN-UG
Если вы хотите получить листинг файлов в DOC FILELIST, то следует послать команду INDEX DOC в LISTSERV-сервер EARNCC, где расположен этот список. Эта команда эквивалентна команде GET DOC FILELIST.
Допустим, вы хотите получить файл PCPROG ZIP из списка файлов в формате XXE. Пошлите команду серверу, где размещен этот файл:
GET PCPROG ZIP F=XXE
Предположим, что вы хотите извлечь все файлы, которые образуют пакет под названием PROGRAM (как видно из файла с названием PROGRAM $PACKAGE) из списка файлов SAMPLE. Пошлите команду:
GET PROGRAM PACKAGE SAMPLE
Если вы хотите подписаться на файл под названием BUDGET MEMO в списке файлов EXPENSES с помощью AFD, тогда воспользуйтесь командой:
AFD ADD BUDGET MEMO EXPENSES
Чтобы подписаться на файл с названием VM EMAIL в DOC FILELIST с помощью FUI, вам следует послать следующую команду в LISTSERV узла EARNCC:
FUI ADD VM EMAIL DOC
Ниже приведен пример реализации LIST-сервера, который использован для обмена информацией о московском опорном магистрали (LIST-сервер "FBONE-OP").
LIST-сервер "FBONE-OP" - система обслуживания и управления списком адресов электронной почты. Она позволяет группам ученых, пользующихся услугами южной части московской оптоволоконной магистрали, общаться между собой. Доступ к серверу может получить всякий пользователь, который имеет доступ к электронной почте. Система реализована на версии Majordomo. Это разработка Brent Chapman'а, версия 1.93.
В описании, приведенном ниже параметры, которые помещены в ] являются опционными. Если вы задаете эти параметры, не помещайте их в [ ].
Для того, чтобы наладить контакт с сервером нужно послать запрос по адресу: FBONE-OP-REQUEST@ITEP.RU. Серверу можно послать несколько команд в одном сообщении. Каждая команда должна начинаться с новой строки. Поле subject при этом игнорируется. Ниже описаны наиболее часто используемые команды. Команды имеют следующий формат: прописные буквы указывают на возможное сокращение, угловые скобки выделяют опционный параметр, а вертикальная черта отмечает значение этого параметра. Существует стандартный набор параметров ключевых слов, которые могут использоваться совместно с командами в качестве параметров.
При работе с LIST-сервером помимо уже описанных (subscribe, unsubscribe, get и index) могут использоваться следующие команды:
which [<address>]
Определить, на какой из списков вы подписаны (или адресат <address>).
who [<list>]
Определить список подписчиков <list>.
info [<list>]
Выдать общую вводную информацию для указанного списка <list>.
lists
Отображает список списков, которые обслуживаются Majordomo-сервером.
end
Блокирует дальнейшую обработку команд (полезно, если вы используете "подпись" в вашей почтовой программе).
Команды должны записываться в тело почтового сообщения (а не в поле Subject) FBONE-OP@ITEP.Ru или FBONE-OP-REQUEST@ITEP.Ru.
В ответ на запрос subscribe вы получите отклик вида:
Received: by ns.itep.ru id AA03442 (5.67a8/IDA-1.5 for semenov); Sun, 26 Feb 1995 12:29:44 +0300
Date: Sun, 26 Feb 1995 12:29:44 +0300
To: semenov
From: MailList
Subject: ITEP MailLists Server results
Reply-To: MailList
>>>> subscribe
Succeeded.
Параметр <list> является опционным, если запрос послан по адресу "<list>-request@ITEP.Ru". В ответ на запрос who сервер выдаст:
From maillist Sun Feb 26 15:46:16 1995
Received: by ns.itep.ru id AA07983
Date: Sun, 26 Feb 1995 15:46:15 +0300
To: semenov
From: MailList
Subject: ITEP MailLists Server results
Reply-To: MailList
>>>> who
Members of list 'fbone-op':
bobyshev
BOBYSHEV@vxdesy.desy.de
bobyshev@x4u2.desy.de
kent@top.rector.msu.su
ks@isf.ru
em@free.net
gonchar@ipsun.ras.ru
noc@radio-msu.net
sid@free.net
nelubov@oea.ihep.su
sakr@itp.ac.ru
leonid@egoshin.ihep.su
semenov
При работе c подписными листами следует прежде всего думать о партнерах по списку. Это занятые люди, поэтому для всеобщего внимания следует выносить лаконичные сообщения, представляющие всеобщий интерес. Частные сообщения лучше посылать только тому, или тем, адресатам, которым это важно знать.
Детальная документация по LISTSERV и связанных с ним услуг доступна в DOC FILELIST по адресу LISTSERV@EARNCC.BITNET. Сюда входит LISTSERV User Guide, который доступен в обычном и postscript форматах. Для получения списка доступной документации используйте команду INDex. Существует несколько списков для обсуждения технических вопросов LISTSERV. Они не предназначены для обычных пользователей, но и не закрыты для них. Это:
LSTSRV-L технический форум LISTSERV.
LSTOWN-L форум хозяев списков LISTSERV.
LDBASE-L форум возможностей баз данных в LISTSERV.
SET и другие системы осуществления платежей
4.6.2 SET и другие системы осуществления платежей
Семенов Ю.А. (ГНЦ ИТЭФ)
Безопасность системы должна препятствовать воровству денег на всех этапах выполнения операции.
Себестоимость операции должна быть низкой для всех участников.
Система должна обеспечивать высокий уровень конфиденциальности для клиента.
Схема и реализация должны быть простыми (не нужно использовать сложных протоколов)
Система должна быть открытой (протоколы и тесты программ должны быть общедоступны).
Система должна уметь выполнять операции с любыми долями самой мелкой денежной единицы.
Должна предоставлять достаточное количество данных для целей аудита.
Система должна быть свободной, то есть не иметь ограничений владельца.
Ни одна из существующих платежных систем не отвечает всем этим требованиям в полной мере. Существует много платежных схем, например:
А. Электронные монеты
Б. Электронные чеки
В. Электронные переводы (трансферты)
Разумеется, могут существовать и методы, сочетающие в себе любые комбинации этих схем. Эти методы должны работать не только с традиционными деньгами, но с их заменителями, акциями, облигациями, золотыми слитками, товарами и услугами. Во всех моделях помимо основных участников – продавца и покупателя, необходим посредник. Назовем его банкиром (кассиром). Теперь рассмотрим названные выше платежные модели более подробно.
Модель электронных монет
Эта схема моделирует традиционную денежную систему. Банкир формирует цифровые сертификаты, называемые монетами, и приобретаемые участниками сделок. Эти сертификаты могут быть банкиром выкуплены. Клиенты используют эти сертификаты (монеты) для расчетов как обычные деньги. Эту модель достаточно трудно реализовать из-за проблемы повторного использования сертификатов для покупок. Есть у этой модели и преимущества, например, плательщик не должен иметь контакт с банкиром в реальном масштабе времени в момент платежа, да и уровень конфиденциальности здесь вполне приемлем.
Модель электронных чеков
Данная модель с хорошей точностью воспроизводит практику применения обычных чеков. Клиент заполняет электронный чек, который представляет собой платежное поручение. Этот чек подписывается электронным образом и передается партнеру (например, продавцу), который предъявляет его банкиру. Банкир проверяет корректность чека, наличие необходимых средств на счете клиента, заполнившего чек, и, если все в порядке, переводит средства на счет продавца. Преимуществом этой модели является простота, легкость разрешения любых споров, а также отсутствие требование выполнения всех операций в реальном масштабе времени. Уровень конфиденциальности здесь также вполне разумен.
Модель электронных переводов
Данная модель простейшая из описанных. Плательщик выдает платежное поручение банкиру, снабжая его электронной подписью. Банкир верифицирует платежное поручение, проверяет наличие средств и, если все в порядке, осуществляет перевод денег. Операция со стороны плательщика выполняется в реальном масштабе времени. Эта модель прозрачна, получатель перевода не должен быть доступен в реальном масштабе времени. Схема хороша для начисления зарплаты, но совершенно не приемлема для торговли через Интернет.
Теперь рассмотрим требования к безопасности платежной системы. В случае работы через Интернет эти требования должны быть достаточно жестки, так как сами транспортные протоколы TCP/IP практически не предоставляют сколько-нибудь существенной защиты.
Никто кроме владельца счета не может иметь к нему доступа, и никто не должен иметь возможности имитировать работу владельца счета.
Плательщик должен иметь возможность доказать третьей стороне, что платеж произведен и предоставить данные о предмете платежа. Это необходимо в случае конфликта, когда клиент либо не получил оплаченный товар, либо, например, не удовлетворен его качеством. Здесь нужно учитывать возможность случайного или преднамеренного искажения сообщений при их передаче.
Получатель платежа должен иметь возможность доказать третей стороне, какую сумму, когда, за что и от кого он получил. Это нужно для разрешения возможных конфликтов с клиентом.
Банкир должен иметь возможность доказать третьей стороне, что он при работе со счетами строго следовал платежным поручениям. Это позволит ему отвести обвинения в осуществлении неавторизованных платежных операций.
Плательщик должен быть уверен, что платеж будет осуществлен именно тому продавцу товара или услуг, кому он хотел. Это подразумевает иммунитет системы против преднамеренных искажений платежных сообщений.
Система должна противостоять фальсификации расписок банкира.
Все возможные конфликты между банкиром и его клиентами должны разрешаться с помощью анализа сообщений, снабженных электронными подписями.
Конфликты между клиентами должны разрешаться без участия банкира.
Система должна быть устойчива против любых форм фальсификации. Даже в случае раскрытия секретного ключа клиента, она не должна допускать слишком больших потерь.
Не менее важную роль имеет конфиденциальность любых финансовых операций.
Посторонние лица не должны получать никакой существенной информации об активности клиентов платежной системы и банкира.
Получатель платежа не должен получать информации, позволяющей идентифицировать плательщика.
Банкир не должен получать информацию о том, какой товар или услуга оплачиваются.
Это не следует рассматривать как исчерпывающий список требований к безопасности и конфиденциальности.
4.6.2.1. Протокол микроплатежей MPTP (Micro Payment Transfer Protocol)
Разработчики технологии WWW, HTML и XML (группа W3C;
http://www.w3.org/TR/WD-mptp-951122) разработали проект платежного протокола, который является модификацией алгоритма Pay-Word, предложенного Ривестом и Шамиром (“PayWord and MicroMint – Two Simple Micropayment Schemes”, R.L. Rivest and A.Shamir; http://theory.lcs.mit.edu/~rivest/RivestShamir-mpay.ps). Электронная коммерция предполагает рекламу, продажу материальных и нематериальных товаров. Материальные товары требуют доставки, что усложняет процедуру купли-продажи. Торговля через Интернет требует минимизации времени отклика для клиента. Кроме того, важно, чтобы издержки, сопряженные с торговыми операциями, составляли небольшую долю стоимости покупки, что становится весьма критично при низкой стоимости приобретаемого товара или услуги. При проектировании новых торговых систем следует учитывать, что процедуры верификации электронной подписи могут выполняться на стандартной рабочей станции со скоростью около 1000/сек, а вычисление однопроходной хэш-функции занимает примерно 10 мксек. Контроль хэш-функции в 100 раз быстрее, чем верификация RSA-подписи, и в 10000 раз быстрее формирования RSA-подписи. Таким образом, современная персональная ЭВМ вполне успешно может решать любые торговые операции даже в режиме сервера, который обслуживает десятки и сотни клиентов одновременно. Время отклика в любом случае не будет превышать одной секунды. Работа в реальном масштабе времени предлагает на два порядка более высокие требования, чем работа в режиме off-line.
Протокол MPTP является асинхронным (большинство операций выполняются в режиме off-line). MPTP не делает различия между покупателем и продавцом. Протокол предполагает существование посредника-брокера (B; банкира), который контролирует счета участников сделок. Под брокером может подразумеваться любая организация, способная работать со счетами достаточно большого числа клиентов при минимальных издержках. Брокером может быть сервис-провайдер (ISP), телефонная компания или банк.
При разработке протокола принимались во внимание следующие риски.
Злоупотребление кредитом (осуществление платежей через счет без реального намерения платить)
Мошенничество (например, направление фиктивного платежного поручения).
Неавторизованный отзыв платежа
Неавторизованная модификация заказа
Ошибка при выполнении кредитной операции
Дублирование платежного поручения (клиентом или третьим лицом)
Отказ от услуги (клиент или продавец отказываются использовать свои счета)
Отказ выполнения платежа
Недоставка (платеж получен, а товар не доставлен).
Протокол поддерживает любую политику платежей, которая может согласовываться покупателем (С) и продавцом (М). Классическим объектом политики является, например, требование предоплаты. При обслуживании малоценных покупок целесообразен определенный уровень доверия и соответствующий ему уровень риска. При этом продавец мониторирует случаи отказов при платежах, выявляя недобросовестных покупателей. Стандартная схема работы с кредитной картой в данном случае является чрезмерно избыточной.
Алгоритм платежа в MPTP основан схеме PayWord (1996 г.), где вычисляется цепочка значений хэш-функций c привлечением схемы MD5 или SHA. Полученные значения имеют 128 или 160 бит, допускается и меньшая длина.
Схема PayWord является кредитной и практически реализует схему электронных монет. Пользователь запрашивает у брокера (банкира) счет и сертификат, передав ему по безопасному каналу номер своей кредитной карты, общедоступный ключ шифрования и адрес доставки (например, E-mail или IP-адрес). Брокер при этом посылает сертификат покупателя СП, который имеет вид:
СП = [B, ID, AП, PKП, E, IП]SKB
где B – идентификатор (имя) брокера; ID – идентификатор покупателя; AП – адрес доставки; PKП – общедоступный ключ покупателя; Е – время истечения действия сертификата ( брокер может обновлять его, например, раз в месяц); IП – дополнительная информация, задаваемая брокером, например, серийный номер сертификата, лимит кредита и т.д.; SKB – секретный ключ брокера. Сертификат СП получен путем шифрования содержимого квадратных скобок с помощью SKB. В некоторых других платежных схемах сертификат формируется клиентом-покупателем. Сертификат устанавливает связь между общедоступным ключом покупателя и его счетом для заданного общедоступного ключа брокера. Предполагается, что общедоступный ключ брокера известен всем участникам платежного процесса. Генерация пар общедоступный-секретный ключ осуществляется каждым участником независимо. Данная схема не гарантирует анонимности (AП!), более того, здесь имеется риск утечки информации о номере кредитной карты пользователя. Сертификат гарантирует продавцу, что платежные слова (payWord) покупателя будут выкуплены брокером.
Далее будем предполагать, что чтение одной страницы на коммерческом сервере продавца стоит один рубль (стоимость одного платежного слова согласуется на фазе инсталляции сессии).
Когда пользователь обращается к коммерческой странице продавца, его броузер определяет, является ли данный вызов первым в этот день. Если это первое обращение, программа покупателя формирует и подписывает обязательство, сопряженное с цепочкой платежных слов w1, w2, …, wn, где wn выбирается случайным образом. Значение n определяется клиентом. Все остальные платежные слова вычисляются рекурсивно, согласно соотношению:
wi = H(wi+1) для i= n-1, n-2,…,0. Здесь w0 является корнем цепочки платежных слов, а не платежным словом. H – представляет собой однопроходную хэш-функцию типа MD5 или SHA. После этого клиент передает программе продавца обязательство и свой сертификат, программа верифицирует эти данные, используя общедоступный ключ брокера.
i-платеж (для i = 1, 2, …) продавцу состоит из пары чисел (wi,i). Продавец может проверить это посылку, используя значение wi-1. Стоимость всех платежных слов (PayWord) w1, w2, …, wn идентична. Каждый платеж не предполагает каких-либо вычислений в программе покупателя и лишь одну хэш-операцию в программе продавца.
Платежи должны быть индексированы в соответствии с порядком (i) сформированных платежных слов. Это исключает повторное использование платежных слов. Но возможна передача после платежного слова wi платежного слова wi+10, это будет означать оплату очередной покупки стоимостью 10 рублей (если одно платежное слово стоит один рубль). В конце каждого дня продавец передает брокеру последнее платежное сообщение за этот день (wl, L) каждого из покупателей, добавляя к нему соответствующее обязательство. Брокер снимает со счета покупателя L рублей (L платежных слов) и переводит их на счет продавца. Предполагается, что существует всего несколько брокерских центров на страну. Практически все операции выполняются в режиме off-line, а брокер не получает даже сообщений о каждом платеже (а только о последнем за данный день). Заметим, что в данной системе не специфицируется явно то, за какой товар или услугу осуществлен платеж.
В некоторых платежных схемах обязательство выполняет функцию электронной кредитной карты или чека.
4.6.2.2. MicroMint
MicroMint (при вольной интерпретации это выражение можно перевести как микромонетный двор) представляет собой еще одну платежную систему, базирующуюся на модели электронных монет. Здесь не используется общедоступный ключ шифрования. Электронные монеты в этой схеме формируются брокером, который продает их пользователям. Пользователи передают эти монеты продавцам в качестве оплаты товаров или услуг. Продавцы возвращают эти монеты брокеру, который осуществляет перевод реальных денег на счет продавца.
Электронная монета представляет собой последовательность бит, которая может быть легко проверена, но которую достаточно трудно сформировать. Алгоритм MicroMint устроен так, что формирование большого числа монет стоит дешевле (из расчета на одну монету), чем формирование одной или нескольких. Брокер формирует партию монет, например раз в месяц. При этом действие прежней партии монет истекает, и они не могут более использоваться. Продавцы возвращают полученные монеты в конце каждого дня.
Монеты MicroMint формируются с использованием кратных столкновений хэш-функций. Однопроходная хэш-функция H ставит в соответствие m битам строки х n бит строки y. Строка х называется исходным образом y, если H(x)=y. Пара строк (х1,х2) называются двойным столкновением, если H(x1)=H(x2)=y, где строка y имеет n бит. Если хэш- функция гарантирует достаточно высокий уровень рэндомизации, то для получения одного двойного столкновения необходимо вычислить для строки х примерно 2n/2 xэш-функций. Но при ограниченном n вычисление двойных столкновений является относительно простой задачей и для злоумышленника, по этой причине для формирования монет чаще используется вычисление k-кратных столкновений.
k-кратным столкновением называется набор строк х1, х2, …, хk для которых H(x1)=H(x2)=…=H(xk)=y. Для получения k-кратного столкновения необходимо выполнить вычисление примерно 2n(k-1)/k хэш-функций. В дальнейшем будем считать, что монета характеризуется k-кратным столкновением (х1, х2, …, хk). Корректность монеты может проверить кто угодно, вычислив k хэш-функций и проверив условие.
H(x1)=H(x2)=…=H(xk)=y
Если в ходе вычисления хэш-функций просматривать результат, то можно выявить определенное число k-кратных столкновений, что во много раз увеличивает производительность генерации электронных монет. Еще большего выигрыша в скорости можно достичь, применяя специфические аппаратные реализации.
Предположим, что брокер хочет иметь чистый доход размером в 1 млн. долларов США (эквивалентно примерно 227 центов/месяц). Пусть доходы брокера составляют 10%, это означает, что продавец получает 0,9 цента при выкупе монеты. Таким образом, брокер должен продать миллиард монет в месяц. Если обычный клиент покупает 2500 монет в месяц, необходимо иметь 500000 клиентов.
Пусть k=4 (4-кратные столкновения). Для того чтобы сформировать 230 монет, надо будет закупить специализированное оборудование стоимостью около 100000$ (что менее 10% месячного дохода). Для целей вычисления хэш-функций могут использоваться специализированные ИС, применяемые для DES-шифрования или ИС FPGA – программируемые логические матрицы. Подготовка брокером нового набора монет может продолжаться в течение всего месяца. Нетрудно понять, что злоумышленнику, использующему обычную рабочую станцию, сформировать самостоятельно достаточное число монет не по плечу.
При продаже монет клиенту брокер запоминает, какому клиенту какие монеты проданы, что позволяет в будущем проконтролировать попытки злоупотреблений. Неиспользованные монеты ликвидируются в конце месяца. Ограничение времени действия монет создает определенные трудности для клиента. Но за то это ограничивает требуемые объемы баз данных, хранящих информацию о выпущенных и использованных уже монетах. Монетная система по своей природе предполагает определенное доверие между плательщиком и получателем платежа. Получатель может присвоить монету и заявить, что она уже была использована, а плательщик может предъявить претензии получателю (банку или продавцу), утверждая, что повторного использования не было, а монета просто присвоена. В сущности, это является общим свойством любых монет и сертификатов на предъявителя.
Каждый раз, когда клиент осуществляет покупку, он пересылает продавцу одну или несколько монет (х1, х2, …, хk). Это может осуществляться автоматически программой WEB-броузера. Продавец проверяет корректность монет путем вычисления k функций H(xi), что занимает совсем немного вычислительных ресурсов. При возвращении монет продавцом брокеру проверка повторяется.
Существуют методы формирования монет специфических для клиента или для продавца, что снижает риски злоупотреблений (смотри “PayWord and Micromint: Two simple micropayment schemes” Ronald L. Riverst и Adi Shamir, 7 мая 1996).
Мелкомасштабная атака малоэффективна, и по этой причине недостойна серьезного внимания (злоумышленник должен понести большие издержки из-за нескольких центов). Для такого рода атак для k=4 и n=54 при использовании стандартной рабочей станции требуются десятки лет.
Крупномасштабное мошенничество легко детектируется из-за следующих обстоятельств.
Все фальшивые монеты теряют силу в конце месяца.
Фальшивые монеты могут быть сформированы после того, как брокер выбросил на рынок новую партию монет в начале месяца.
Брокер может обнаружить присутствие фальшивок из-за того, что некоторые фальшивые монеты неизбежно не соответствуют ни одной из настоящих, которые все зарегистрированы.
Брокер может в любой момент объявить об истечении срока годности выпущенных в оборот монет и запустить в оборот новую партию.
Возможность кражи монет в ходе пересылки блокируется с помощью шифрования, что легко осуществить, так как взаимоотношения между клиентами продавцами и брокерами являются долгосрочными и доверительными. Схема MicroMint не является анонимной, поэтому брокер легко может детектировать попытки повторного использования монет. Обнаружить мелкого злоумышленника трудно, но из-за низкой цены монет это не может вызвать проблем. Генерация монет, специфических для клиента или продавца делают кражу бесполезной.
Таким образом, любые злоупотребления легко обнаруживаются, но так как в MicroMint не используются подписи, выяснение отношений в суде невозможно.
Для генерации монет, специфических для клиентов, последние делятся брокером на группы. Например, клиенту U даются монеты, которые дополнительно отвечают требованию h(х1, х2, …, хk)=h(U), где h – хэш-функция, формирующая 16-битовый код. Данное решение может оказаться не слишком хорошим для больших групп, где вор всегда сможет найти клиента, желающего приобрести украденные монеты. При малых же группах брокер будет вынужден производить слишком большую вычислительную работу.
Другим вариантом может быть обобщение понятия столкновения. Монета (х1, х2, …, хk) будет считаться корректной для клиента U, если образы y1=(x1), y2=(x2),…, yk=(xk) удовлетворяют условию yi+1 – yi = di (mod 2u) для i =. 1,2,..,k-1, где (d1,d2,…,dk-1)=h(U). Стандартный алгоритм формирования монет соответствует случаю, когда все значения d равны нулю. Формирование монет специфических для продавца может осуществляться согласно алгоритму, схожему с выше описанным.
Существуют алгоритмы, которые позволяют сократить вычислительные издержки при массовой генерации монет сразу на несколько месяцев.
Другие системы для осуществления небольших платежей, например, NetBill предлагают дополнительные возможности (например, заказы товара и шифрование информации о покупке), но они относительно дороже.
4.6.2.3. Безопасный протокол электронных платежей SET
Для операций с кредитными карточками используется протокол SET (Secure Electronic transactions; см. http://www.visa.com/cgi-bin/vee/sf/standard.html http://www.citynet.net/personal/till/set1.htm), разработанный совместно компаниями Visa, MasterCard, Netscape (http://www.netscape.com) и Microsoft (см. также достаточно полное англоязычное описание протокола по адресу ftp://saturn.itep.ru/../set_bk1.pdf и т.д. “SET - Secure Electronic Transaction Specification”). Полная документация по SET имеет объем около 970 страниц. Данная статья является изложением базовых принципов и понятий. В отличие от SSL протокол SET узко специализирован. Целью SET является обеспечение необходимого уровня безопасности для платежного механизма, в котором участвует три или более субъектов. При этом предполагается, что транзакция реализуется через Интернет. В РФ в настоящее время разработано и разрабатывается большое число различных платежных программ, некоторые из них достаточно совершенны. Здесь следует иметь в виду, что если российские торговые компании и банки не хотят оказаться в изоляции, если они не будут учитывать складывающиеся тенденции и стандарты, шансов конкурировать на международном, а вскоре и на отечественном рынке у них не будет. Для этого нужно снять ряд юридических ограничений, действующих в РФ и блокирующих развитие электронной торговли (это касается прежде всего алгоритмов RSA, электронной подписи и т.д.). На базовом уровне SET осуществляет следующие функции:
Аутентификация. Все участники кредитных операций идентифицируются с помощью электронных подписей. Это касается клиента-покупателя, продавца, банкира, выдавшего кредитную карточку, и банкира продавца.
Конфиденциальность. Все операции производятся в зашифрованном виде.
Целостность сообщений. Информация не может быть подвергнута модификации по дороге в противном случае это будет сразу известно.
Подсоединение. SET позволяет подключить к базовому сообщению дополнительный текст и послать его одному из партнеров.
Безопасность. Протокол должен обеспечить максимально возможную безопасность операции, достижимую в имеющихся условиях.
Совместимость. Должна быть предусмотрена совместимость с любыми программными продуктами и с любыми сервис-провайдерами.
Независимость от транспортного протокола. Безопасность операций не должна зависеть от уровня безопасности транспортного протокола. Такие гарантии особенно важны, так как протокол SET ориентирован для работы в Интернет.
На более высоком уровне протокол SET поддерживает все возможности, предоставляемые современными кредитными карточками:
Регистрацию держателя карточки
Регистрацию продавца
Запрос покупки
Авторизацию платежа
Перевод денег
Кредитные операции
Возврат денег
Отмену кредита
Дебитные операции
Окончательная версия протокола SET была выпущена в мае 1997 года. Протокол работает с четырьмя субъектами: владельцем кредитной карточки, банком, эту карточку выпустившим (issuer - эмитент), продавцом (merchant) и банком, где помещен счет продавца (acquirer). Помимо этих функциональных субъектов в процессе обычно (опционно) участвует центры сертификации, в задачу которых входит подтверждение подлинности предъявляемых параметров аутентификации, причем в случае крупных сделок с этими центрами должны взаимодействовать все участники. Основной целью сертификатов является подтверждение того, что присланный общедоступный ключ прибыл от настоящего отправителя, а не от самозванца.
Практика электронной торговли позволяет выделить семь этапов сделки.
В реальном масштабе времени на WEB-сервере
На CD-диске на своей рабочей станции
Читая бумажную версию каталога
Через поисковую систему посредника
Многие современные WEB-броузеры поддерживают протокол SET. Что позволяет осуществлять торговлю товарами и услугами с использованием WWW-технологии. Напрашивается вопрос, почему для финансовых операций не использовать протокол SSL, который весьма широко распространен? SSL позволяет безопасно передавать продавцу номер кредитной карточки покупателя, но не способен реализовать многие другие операции, например, проверить этот номер на правильность, проконтролировать, позволено ли данному клиенту пользоваться данной карточкой и т.д.. Конечно, не трудно создать CGI-скрипты, которые решат некоторые из этих проблем, но это не может заменить контроля в реальном масштабе времени, необходимого для некоторых операций. Нельзя утверждать, что в рамках протокола SSL нельзя решить и эти проблемы, но для этого нужно создать достаточно большое число специализированных программ, которые в существующих пакетах пока отсутствуют. Кроме того, нужно думать и о безопасности на стороне сервера. Продавец, получив номер кредитной карточки, может занести его в базу данных. А где гарантия (для покупателя), что эта база данных достаточно хорошо защищена? Таким образом, даже передача номера кредитной карточки посредством SSL не самая лучшая идея. Тем более такая схема позволяет осуществлять подбор номеров кредитных карт. А заботиться об удобствах воров не самое полезное занятие.
Номер кредитной карточки имеет определенную структуру (это не случайное число). Первые четыре цифры – код банка, выпустившего карточку. Последняя цифра представляет собой контрольную сумму номера. Вычисление этой контрольной суммы производится по следующему алгоритму.
Каждая цифра номера умножается на его “вес”. Веса меняются 1,2,1,2. Для карт с четным числом цифр, последовательность весов начинается с 2, в противном случае с 1. Если взвешенное число больше 9, из него вычитается 9. Далее вычисляется сумма по модулю 10. Результат всегда должен получаться равным нулю (с учетом кода контрольной суммы).
Схема взаимодействия субъектов в протоколе SET показана на рис. 4.6.2.1 (взаимодействия с центром сертификации не показаны). Протокол SET помогает реализовать следующие процедуры.
Рис. 4.6.2.1. Схема взаимодействия субъектов протокола SET
Покупатель инициализирует покупку. При этом покупатель выбирает продавца, просматривает его WEB-сайт, принимает решение о покупке, заполняет бланк заказа. Все это делается до вступления в дело протокола SET. Реально взаимодействие участников сделки регламентируется протоколом IOTP. SET начинает свою работу, когда покупатель нажимает клавишу оплаты. При этом сервер посылает ЭВМ-покупателя сообщение, которое и запускает соответствующую программу. Процедура эта может быть реализована с помощью PHP- или CGI-скрипта, или JAVA-аплета.
Программа клиента посылает заказ и информацию об оплате. Для этого формируется два сообщения, одно содержит данные о полной стоимости покупки и номере заказа, второе – номер кредитной карточки покупателя и банковскую информацию. Сообщение о заказе шифруется с использованием симметричного метода (например, DES) и вкладывается в цифровой конверт, где используется общедоступный ключ продавца. Сообщение об оплате шифруется с привлечением общедоступного ключа банка (эмитента кредитной карты). Таким образом продавец не получает доступа к номеру кредитной карточки покупателя. Программа генерирует хэш-дайджест (SHA1) обоих сообщений с использованием секретного ключа покупателя. Это позволяет продавцу и банкиру проконтролировать целостность сообщения, но препятствует прочтению части, ему не предназначенной (например, номера кредитной карты продавцом).
Продавец выделяет часть, адресованную банкиру, и направляет ее по месту назначения. Программа SET WEB-сервера продавца генерирует запрос авторизации серверу банка, где находится счет продавца. При формировании запроса авторизации используется электронная подпись продавца, базирующаяся на его секретном ключе, что позволяет однозначно его идентифицировать. Этот запрос шифруется с помощью ключа сессии и вкладывается в цифровой конверт, где используется общедоступный ключ банка.
Банк проверяет действительность кредитной карточки, дешифрует запрос авторизации продавца и идентифицирует продавца. После этого осуществляется проверка авторизации покупателя. При этом посылается запрос авторизации, снабженный электронной подписью, банку, выпустившему кредитную карточку.
Банк, выпустивший карточку, выполняет авторизацию и подписывает чек, если кредитная карточка покупателя в порядке. Отклик, снабженный соответствующей подписью, посылается банку продавца.
Банк продавца авторизует данную операцию, и посылает подтверждение, подписанное электронным образом, WEB-серверу продавца.
WEB-сервер продавца завершает операцию, выдавая клиенту подтверждение на экран, и заносит результат операции в соответствующую базу данных.
Продавец осуществляет подтверждение выполнения операции своему банку, Деньги покупателя переводятся на счет продавца.
Банк, выпустивший карточку, посылает счет покупателю и SET уведомляет покупателя об изменениях на его счету (раз в месяц).
Итак, видно, что каждый шаг реализации протокола SET сопровождается аутентификацией. Это препятствует какому-то внешнему субъекту стать посредником и видоизменять сообщения. Для нормальной работы протокола SET все участники должны зарегистрироваться и снабдить партнеров своим общедоступным ключом.
Протокол SET может использоваться не только в рамках Интернет, но и при заказах по почте или телефону MOTO (Mail Order/Telephone Order). Для понимания основополагающих принципов вышеизложенного могло бы быть достаточно. Более того, квалифицированный программист мог бы написать программы, которые эти принципы реализовали для некоторой замкнутой системы покупатель-банки-продавец. Но функция SET шире, этот протокол рассчитан на международную ничем не ограниченную систему платежей. По этой причине ниже будут приведены некоторые, наиболее важные детали работы протокола, регламентирующие его функционирование.
В вышеприведенном описании предполагалось, что все субъекты процедуры уже владеют соответствующими ключами. На практике до начала такого обмена все участники должны зарегистрироваться (пройти процедуру аутентификации через соответствующий центр), обменяться общедоступными ключами. Общедоступный ключ сопровождается электронной подписью отправителя (X.509v3). Схема регистрации владельца карты в центре сертификации (СА) показана на рис. 4.6.2.2. Процесс регистрации проходит через 7 состояний, начиная с отправки начального запроса и завершая получением сертификата. Эффективность сертификата при идентификации владельца карты сильно зависит от методов, используемых платежной системой карты и эмитентом карты для аутентификации владельца перед выдачей ему сертификата. Это достаточно критический процесс, учитывая то, что на этом этапе еще не используется цифровая подпись.
Рис. 4.6.2.2. Регистрация владельца карты в центре сертификации
Сертификаты владельцев карт являются электронным представлением самих платежных карт. Так как они подписаны цифровым образом, их не сможет модифицировать третья сторона. Сертификат владельца карты не содержит номера счета и срока ее действия. Вместо этого там закодирована с привлечением хэш технологии информация о счете и секретный код, известный только программе владельца карты. Если номер счета, срок его действия и секретный код известны, корректность сертификата может быть проверена, но извлечь эту информацию из сертификата, даже зная часть перечисленных параметров практически невозможно. В рамках протокола SET владелец карты передает информацию о счете и секретный код расчетному центру, где эта информация верифицируется.
Сертификат посылается владельцу карты только в случае, когда это одобряется финансовой организацией, выпустившей эту карту. Запрос сертификата указывает на то, что владелец карты намерен выполнить какую-то коммерческую операцию. Полученный сертификат передается продавцу в рамках запроса покупки вместе с платежными инструкциями. Получив сертификат владельца карты, продавец может быть уверен, что счет владельца карты существует и действует, что подтверждено эмитентом карты или его агентом. В рамках SET сертификаты владельцев карты опционны и оставлены на усмотрение платежной системы.
Когда сертификационный центр (СА) получает запрос владельца карты, он дешифрует цифровой конверт, получает симметричный ключ, информацию о счете и секретный код, генерируемый программой владельца карты. Собственно запрос сертификата дешифруется с помощью симметричного ключа. Затем СА использует общедоступный ключ, присланный в запросе, чтобы проверить подпись, сформированную с помощью секретного ключа владельца карты. Если с подписью все в порядке, процесс обработки запроса продолжается. Далее производится верификация самого запроса с привлечением информации о счете. На этом этапе СА взаимодействует с эмитентом карты. Это взаимодействие не регламентируется протоколом SET. В некоторых вариантах на данном этапе для верификации запроса привлекаются возможности платежной системы (brand). Если верификация запроса прошла успешно, сертификат формируется и пересылается владельцу карты. При этом СА сначала генерирует случайное число, которое комбинируется с секретным кодом, присланным в запросе. Полученный код используется в сертификате для защиты информации о счете владельца карты. Номер счета, срок его действия и секретный код преобразуются с помощью однопроходного хэш-алгоритма. Полученный результат помещается в сертификат. Если номер счета, срок его действия и секретный код известны, сертификат можно верифицировать. После данной процедуры СА цифровым образом подписывает сертификат. Время действия сертификата определяется политикой СА, но часто оказывается равным сроку работы платежной карты (но может оказаться и короче). Сообщение-отклик содержит в себе сертификат, а также секретный код, сформированный СА и логотип платежной системы. Вся эта информация шифруется симметричным ключом, присланным в запросе. Многие из упомянутых процедур и структуры запросов/откликов будут рассмотрены подробно ниже.
Сертификаты продавца индицируют поддержку определенной платежной системы. Так как сертификаты продавца снабжены цифровой подписью, они не могут быть модифицированы третьей стороной. Эти сертификаты одобряются банком продавца и предоставляют гарантию того, что продавец имеет официальное соглашение со своим банком. Для работы в среде SET продавец должен иметь как минимум пару сертификатов для каждой разновидности, поддерживаемой им платежной системы.
Схема процедуры регистрации продавца показана на рис. 4.6.2.3 и содержит в себе 5 этапов.
Рис. 4.6.2.3. Регистрация продавца.
Продавец должен зарегистрироваться в СА до того, как он получит платежные инструкции от владельца карты или будет участвовать в транзакциях с расчетным центром. Перед посылкой запроса СА продавец должен получить его общедоступный ключ. Продавец должен также скопировать регистрационную форму в своем банке и идентифицировать получателя в запросе регистрации, посылаемом в СА. Регистрационная процедура начинается с посылки СА запроса сертификата СА, содержащего его общедоступный ключ и соответствующую регистрационную форму. СА идентифицирует банк продавца и выбирает подходящую регистрационную форму. В отклик СА вкладывается эта форма и его сертификат, содержащий общедоступный ключ. Этот сертификат продавец в дальнейшем использует в регистрационном процессе. Раз программа продавца имеет копию СА-сертификата, продавец может воспринимать платежные инструкции и обрабатывать транзакции SET. Прежде чем запрос сертификата будет обработан, продавец должен установить связь со своим банком (получателем). Продавцу нужны две пары общедоступных/секретных ключей – для ключевого обмена и для цифровой подписи. Эти ключи формируются программой продавца. Для регистрации продавец заполняет регистрационную форму, внося туда свое имя, адрес, идентификатор и т.д. Вместе с заполненной формой в СА посылается общедоступный ключ продавца. Эта информация подписывается программой продавца. Далее программа генерирует случайный симметричный ключ, который используется для шифрования запроса сертификата. Сам симметричный ключ шифруется с использованием общедоступного ключа СА и помещается в цифровой конверт. Сформированное таким методом сообщение посылается продавцом в СА.
Когда СА получает запрос продавца, он дешифрует цифровой конверт и извлекает оттуда симметричный ключ, который служит для дешифрации запроса. СА использует ключ, содержащийся в сообщении-запросе, для проверки цифровой подписи (проверка того, что сообщение подписано соответствующим секретным ключом). Если с подписью все в порядке, обработка запроса продолжается, в противном случае прерывается и посылается соответствующее уведомление продавцу.
После этого СА проверяет информацию регистрационного запроса, используя известные данные о продавце. Для этого производится обмен между СА и банком продавца (получателем). После успешной верификации этих данных СА формирует и цифровым образом подписывает сертификат продавца. Время действия сертификата определяется политикой СА. Но это время не должно быть больше длительности контракта между продавцом и его банком. Сертификат шифруется сгенерированным новым симметричным ключом, который в свою очередь шифруется общедоступным ключом продавца. Полученный код образует цифровой конверт отклика. Сообщение-отклик посылается продавцу.
Когда программа продавца получает отклик от СА, она дешифрует цифровой конверт и получает симметричный ключ для дешифрования регистрационного отклика, содержащего сертификат продавца.
SET может работать в режиме, когда участники не имеют сертификатов и не прошли аутентификацию. Такой режим сопоставим с использованием SSL для пересылки номера карточки продавцу, и не может рассматриваться как удовлетворительный. В рамках протокола используются следующие значения символов-префиксов участников сделки:
| Символы-префиксы | Участник сделки |
| C | Владелец карты (Cardholder) |
| M | Продавец (Merchant) |
| P | Расчетный центр (Payment Gateway) |
| CA | Сертификационный центр (Certificate Authority) |
Рис. 4.6.2.4. Диаграмма реализации протокола SET
Начальным состоянием покупателя является shopping. Когда решение о покупке принято, программой клиента посылается запрос PReq и система переходит в состояние заказано. Запрос PReq включает в себя инструкцию OI (Order Instruction) и платежную инструкцию PI. Отклик PRes держателю карты может быть прислан немедленно или с некоторой задержкой. Полученная в отклике информация зависит от состояния протокольной машины (принят заказ, транзакция авторизована и т.д.).
Продавец посылает запрос авторизации платежному серверу, но флаг CaptureNow не устанавливается равным “истинно”, так как запрос оплаты (capture request) будет обработан позже. В состоянии авторизовано допускается частичный пересмотр условий сделки, при этом система может вернуться в состояние заказано или остаться в состоянии авторизовано. Продавец теперь имеет платежное обязательство от эмитента карты, но он должен обработать запрос покупки, для того чтобы получить соответствующую оплату. Запрос CapReq переводит транзакцию в состояние приобретено (Captured – сделка оплачена) и заказ обрабатывается.
Если поступит запрос отмены сделки, система возвращается в состояние авторизовано. Далее владелец карты может запросить кредит. В этом случае обрабатывается запрос кредита, переводя транзакцию из состояния покупка осуществлена (sale processed) в состояние кредит выдан (credit issued).
Запрос покупки (Sale Request) используется, когда продавец знает, что заказанный товар на складе и может быть поставлен немедленно при наличии авторизации. Этот запрос используется также в случае заказа товара или услуг, доставляемых через Интернет. Когда расчетный центр (Payment Gateway) обрабатывает запрос, происходит переход транзакции в состояние покупка осуществлена. С финансовой точки зрения состояния sale processed (обработана) и captured (оплачена) являются эквивалентными. В случае необходимости возврата денег клиенту, запрос кредита (CredReq) переводит систему в состояние кредит получен. Следует учитывать, что реализации некоторых компаний не поддерживают частичный возврат денег (сумма из запроса AuthRevReq копируется в сообщение AuthRevRes).
Когда продавец не может выполнить заказ в полном объеме сразу, он поставляет имеющиеся в наличии товары, а нехватающие заказывает дополнительно. Продавец может предложить клиенту различные схемы оплаты, например, осуществить оплату заказа в несколько этапов, или в случае предоставления Интернет услуг оплата может происходить на регулярной основе раз в месяц без участия самого держателя кредитной карты.
Протокол SET позволяет расчетному центру (Payment Gateway) определять, будет ли продавец получать номер счета владельца карты. Если эмитент карты решает не выдавать эту информацию, продавцу должен быть предоставлен какой-то другой механизм для возвращения сдачи в рамках текущей транзакции. Для этих целей в рамках транзакции предусмотрено несколько полей:
XID |
20-байтовое число, которое однозначно идентифицирует транзакцию (включает в себя все аутентификационные и клиринговые сообщения). |
RRPID |
20-байтовое число, которое однозначно идентифицирует запрос. |
locallD-M |
1-20 байтовый локальный идентификатор, присваиваемый транзакции программой продавца |
paySysID |
1-64 байтовый идентификатор транзакции |
MerOrderNum |
1-25 байтовый номер заказа продавца |
/p> Рассмотрим более подробно функции субъектов протокола SET.
Держатель карты (Cardholder) |
Авторизованный владелец платежной карты, предоставленной ему эмитентом и предназначенной для выполнения платежей за покупки и услуги. |
Продавец (Merchant) |
Субъект или фирма, предлагающие товары, информацию или услуги, получающие от этого прибыль в виде платежей. |
Эмитент (Issuer) |
Финансовая организация, которая осуществляет выпуск платежных карт для клиентов и поддерживает функционирование их счетов. Эмитент гарантирует осуществление платежа для авторизованной транзакции. |
Получатель (Acquirer) |
Финансовая организация, которая поддерживает продавцов, осуществляя операции с платежными картами. Получатель осуществляет сбор финансовых данных, имеющих отношение к транзакции, для получения авторизации платежа, который выполняет эмитент. |
Расчетный центр (Payment Gateway) |
Система, которая предоставляет коммерческие услуги продавцам через посредство получателя, и обеспечивает интерфейс получателю для авторизации и реализации транзакции. Расчетный центр обычно управляется получателем. |
Платежная система (Brand) |
Система или компания, предоставляющая платежные средства (например, карты VISA, MasterCard и т.д.) |
Сертификационный центр (Certificate Authority –CA) |
Агент одной или нескольких систем платежных карт, который осуществляет создание и рассылку сертификатов для продавцов, покупателей и расчетных центров. Участники транзакции могут иметь единый сертификационный центр, но могут работать и с разными центрами. Основная задача СА – гарантия того, что данное сообщение, ключ и т.д. посланы определенным субъектом, а не самозванцем. |
В SET под владельцем платежной карты подразумевается программа, работающая на рабочей станции клиента-покупателя. Эта программа обеспечивает доступ к серверам продавцов, если требуется, поддерживает диалог между покупателем и продавцом, и реализует платежный процесс. При этом посылается заказ, получается отклик на этот заказ, осуществляются, если требуется, дополнительные информационные запросы и получаются данные о ходе реализации транзакции.
Эта программа выполняет опосредованную связь с получателем. Зашифрованные платежные данные через систему продавца поступают в расчетный центр, где они дешифруются.
Программа продавца предоставляет интерфейс для взаимодействия с программой владельца платежной карты, с программой получателя (Acquirer – банк продавца) и с центром сертификации. Эта программа авторизует транзакцию, инициированную владельцем карты. Выполнение криптографических операций может производиться на аппаратном уровне. Такие криптографические модули могут быть снабжены также аппаратными устройствами генерации и запоминания секретных ключей (например, смарт-карты).
Важной функцией расчетных центров помимо реализации платежей является поддержка списков аннулированных сертификатов CRL (Certificate Revocation List). Это крайне важно для вовлеченных финансовых организаций и фирм предоставляющих платежные средства (например, таких как VISA или MasterCard).
Сертификаты расчетного центра (РЦ) пересылаются банку продавца (получателю) и служат для обработки сообщений авторизации и платежей. Ключ шифрования расчетного центра, который получает владелец карты из сертификата РЦ, используется для защиты информации о счетах владельца карты.
Сам банк продавца (получатель) должен иметь сертификаты для того, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от продавцов. Банк продавца получает свои сертификаты из платежной системы (brand).
Эмитент карт должен владеть сертификатами, чтобы взаимодействовать с сертификационным центром, который может получать и обрабатывать запросы, поступающие непосредственно от владельцев карт. Эмитент получает сертификаты также из платежной системы.
Протокол SET определяет иерархию сертификационных центров, во главе которой находится RCA (Root Certificate Authority). Далее следуют BCA (Brand-specific CA) и GCA (Geo-political CA). Некоторые платежные системы имеют свои сети, например, VisaNet или BankNet. Эти сети осуществляют авторизацию платежей от эмитента к получателю и имеют свою систему защищенной передачи сообщений (ISO 8583).
Цифровая подпись устанавливает соответствие между подписанными данными и уникальным секретным ключом подписанта (покупателя, продавца, банкира или центра сертификации). Секретный ключ математически связан с общедоступным ключом, и таким образом, связывает данные и общедоступный ключ. Фундаментальной целью сертификата является установление соответствия между общедоступным ключом и уникальным идентификатором объекта (или субъекта), гарантируя отсутствие подмены. Следует помнить, что общедоступные ключи пересылаются по незащищенным каналам Интернет. В случае держателя карты сертификат подписи устанавливает соответствие между его общедоступным ключом и индивидуальным кодом PAN (Primary Account Number). Цифровая подпись в сочетании с хэшированием сообщения (вычислением его цифрового дайджеста) гарантирует, кроме того, целостность данного сообщения, блокируя возможность его модификации в процессе пересылки. Сообщения SET следуют рекомендациям ISO/IEC и ITU-T ASN.1 (Abstract Syntax Notation) и кодируется с использованием правил DER (Distinguished Encoding Rules). Механизм пересылки сообщений между объектами SET не регламентируется. Предполагается, что приложения SET могут работать в одном из двух режимов.
Интерактивном, когда объекты взаимодействуют в реальном масштабе времени с малыми задержками между запросами и откликами (например, в рамках технологии WWW).
Не интерактивном, когда задержки между запросом и откликом велики, например, при использовании электронной почты.
Каждая платежная система обеспечивает поддержку CRL в пределах зоны своей ответственности. Архитектура SET использует концепцию BrandCRLidentifier (BCI). BCI подписывается цифровым образом представителем платежной системы.
Протокол SET предполагает использование пар общедоступный/секретный ключ платежными центрами и продавцами обязательным и рекомендательным для владельцев карточек. SET использует стандарты PKCS (Public Key Cryptography Standards). Разработчики программ и систем должны обращать особое внимание на способы хранения секретных ключей. Настоятельно рекомендуется применение аппаратных средств для генерации ключей и шифрования. В настоящее время такие модули предлагаются и для обычных рабочих станций. Особые меры безопасности должны быть приняты для центров сертификации, так как именно они выступают гарантами корректности и безопасности применения общедоступных ключей участников транзакций.
Информация о счете владельца карты для продавца шифруется его общедоступным ключом. Доступ продавца к этой информации является опционным, (см. замечания выше). При выборе данной опции должны быть приняты меры для обеспечения конфиденциального хранения этих данных на сервере продавца. Как минимум эта информация должна храниться в зашифрованном виде и к ней должен быть ограниченный доступ.
Так как сертификаты, CRL и BCP используются достаточно часто при обработке сообщений SET, должен быть создан безопасный кэш для их хранения.
Так как объем транспортируемых протокольных структур весьма велик, для сокращения трафика используется механизм оттисков (thumbprints). Оттиск представляет собой хэш сертификата, CRL или BCI. Точнее это хэш SHA-1 одного из перечисленных объектов, снабженный цифровой подписью.
Цифровой конверт сообщения (MessageWrapper)
. MessageWrapper является информационной структурой верхнего уровня (ASN.1/DER) протокола SET. Эта структура размещается в самом начале сообщения и часто не шифруется. Она определяет тип MessageWrapper, информационные поля цифрового конверта представлены в таблице 4.6.2.1.
Таблица 4.6.2.1
. Поля MessageWrapper
| Название поля | Описание |
Message-Wrapper |
{MessageHeader, Message, [MWExtension]}} |
MessageHeader |
{Version, Revision, Date, [MessageID], [RRPID], SWIdent} |
Version |
Версия SET-сообщения |
Revision |
Подтип SET-сообщения |
Date |
Дата генерации сообщения |
MessageID |
{[LID-C], [LID-M], [XID]} |
RRPID |
Идентификатор, позволяющий объединять в пары запросы и отклики |
SWIdent |
Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов |
Message |
< PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error> |
LID-C |
Локальный идентификатор, генерируемый системой владельца карты или для его системы |
LID-M |
Локальный идентификатор, генерируемый системой продавца или для его системы |
XID |
Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes) |
MWExtension |
Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности. |
/p> Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений.
При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа.
При описании протокола используется нотация представленная в таблице 4.6.2.2.
Таблица 4.6.2.2
. Нотация протокола SET
| Понятие | Нотация | Описание | |
| Группа (tuple) | {A,B,C} | Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы | |
| Компонент | T={A,B,C} | Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т. | |
| Упорядоченное объединение | A|B|C | Служит для обозначения упорядоченного объединения элементов A,B и C | |
| Опционное значение | [A] | Значение A является опционным | Допускается любое вложение этих скобок |
| Выбор | <A,B,C> | Обозначает, что должно присутствовать одно из значений A,B или C | |
| Опционный выбор | [<A,B,C>] | То же, что и предыдущее, но сам выбор опционен | |
| Кратное использование | {A+} | Группа содержит один или более элементов A | |
| {A*} | Группа содержит нуль или более элементов A | ||
| {[A]+} |
Означает, что группа содержит: один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать) |
||
| Исключающее ИЛИ |
A |
Обозначает операцию исключающее ИЛИ |
Таблица 4.6.2.3
. Операторы, используемые протоколом SET
| Нотация | Оператор | Описание |
| H(t) | хэш | 160-битовый хэш группы t |
| HMAC(t,k) | Ключевой хэш-механизм |
160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1 HMAC(t,k) = H(k A opad) | H((k A ipad)|t)), где ipad - байт 0х36, повторенный 64 раза; opad – байт 0х5С, повторенный 64 раза; а A - знак операции исключающее ИЛИ. |
| L(t1,t2) | Связь | Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)} |
| Нотация операторов цифровой подписи | ||
| S(s,t) | Подписанное сообщение | Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7. |
| Нотация операторов двойной цифровой подписи | ||
| SO(s,t) | Только подпись | Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. |
| Нотация операторов шифрования | ||
| E(r,t) |
Асимметричное шифрование (цифровой конверт) | Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData. |
| EH(r,t) | Шифрование целостности | Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте. |
| EX(r,t,p) | Дополнительное шифрование |
Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t – группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p – параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r. |
| EXH(r,t,p) | Дополнительное шифрование с обеспечением целостности | Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH |
| EK(k,t) | Симметричное шифрование посредством ключа k | Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData |
| Нотация операторов инкапсуляции | ||
| Enc(s,r,t) | Простая инкапсуляция с подписью | Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData |
| EncK(k,s,t) | Простая инкапсуляция с подписью и предоставленным ключом | Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData. |
| EncX(s,r,t,p) | Дополнительная инкапсуляция с подписью | Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP |
| EncB(s,r,t,b) | Простая инкапсуляция с подписью с загрузкой | Подписанное зашифрованное сообщение с загрузкой (baggage) |
| EncBX(s,r,t,p,b) | Дополнительная инкапсуляция с подписью и загрузкой | Подписанное, Е-шифрованное составное сообщение с загрузкой |
/p>
OAEP
– Bellare-Rogaway Optimal Asymmetric Encryption Padding
HMAC – ключевой хэш-механизм, базирующийся на алгоритме SHA-1.
В операциях с общедоступными ключами и сертификатами в SET используется алгоритм RSA. Обычно длина ключа составляет 1024 бита и только для Root CA (базового центра сертификации) применяются ключи длиной 2048 бит.
Для симметричного шифрования обычно применяется алгоритм DES. Помимо него используется также алгоритм CDMF (Commercial Data Masking Facility), он служит для защиты сообщений между получателем и держателем карты. DES работает с блоками данных 64 бита и предполагает использование для операций шифрования и дешифрования одного и того же 56-битного ключа (каждый байт содержит бит четности). Правила заполнения SET для DES-CBC требуют, чтобы строка заполнителя всегда добавлась к открытому тексту, подлежащему шифрованию. Заполнитель делает длину блока данных кратной 8 октетам. Если BL представляет конечную длину блока данных, тогда длина строки заполнителя состоит из 8 –(||BL||mod 8) октетов. Каждый из байтов заполнителя содержит код 8 –(||BL||mod 8).
Когда длина заполнителя равна одному октету, код октета равен 01. При длине строки в два байта код строки заполнителя будет равна 0202, а при трех байтах – 030303.
Алгоритм CDMF осуществляет скремблинг данных, который базируется на DES в несколько облегченной модификации, когда эффективная длина ключа равна 40 бит вместо 56 – для DES. По этой причине алгоритм CDMF называется алгоритмом маскирования, а не шифрования. Транспортировка ключа CDMF осуществляется в рамках SET-сообщений также как и ключей DES.
SET использует усовершенствованный Матиасом и Джонсоном метод хэширования, улучшающий технику OAEP.
Общая схема процесса шифрования и дешифрования, представляемая с привлечением общепринятых персонажей Алисы (отправитель шифрованного сообщения) и Боба (получатель) представлена в таблице ниже.
| Шаг | Действие |
| 1 | Алиса запускает программу вычисления дайджеста сообщения, которое она намерена послать Бобу. Этот дайджест будет использован для проверки отсутствия модификации сообщения в процессе его транспортировки от Алисы к Бобу. |
| 2 | Алиса шифрует дайджест сообщения с использованием своего секретного ключа, формируя цифровую подпись. |
| 3 | Формируется псевдослучайный код (симметричный ключ) и с помощью его шифруется сообщение, цифровая подпись и сертификат Алисы, который содержит в себе ее общедоступный ключ. Чтобы дешифровать данное сообщение Бобу будет нужен указанный выше симметричный ключ. |
| 4 | Сертификат Боба, который Алиса должна была получить заранее, содержит копию общедоступного ключа Боба. Чтобы гарантировать безопасность пересылки симметричного ключа, Алиса должна зашифровать его с использованием общедоступного ключа Боба. Зашифрованный таким способом симметричный ключ заносится в одно из полей цифрового конверта (иногда единственное поле), куда в свою очередь будет вложено зашифрованное сообщение. |
| 5 |
Алиса посылает сообщение Бобу. При этом в его состав входит: Сообщение, зашифрованное с применением симметричного ключа, цифровая подпись, сертификат и асимметрично зашифрованный симметричный ключ (цифровой конверт). |
| 6 | Боб получает сообщение от Алисы, дешифрует ключ-конверт с привлечением своего секретного ключа и получает в свое распоряжение симметричный ключ. |
| 7 | Боб использует симметричный ключ для дешифрования текста сообщения, подписи Алисы и ее сертификата. |
| 8 | Осуществляется дшифрация подписи Алисы с привлечением ее общедоступного ключа, который берется из ее сертификата. В результате получается дайджест посланного сообщения. |
| 9 | Боб независимо вычисляет дайджест полученного сообщения с привлечением того же алгоритма, что был использован Алисой. |
| 10 | Полученный и вычисленный дайджесты сравниваются. Если они совпадают, значит, сообщение не было модифицировано по дороге и было послано именно Алисой, а не кем-то кто выдается себя за нее (предполагается, что только Алиса знает свой секретный ключ). Несовпадение дайджестов означает, что, либо сообщение было модифицировано после его подписания Алисой, либо отправлено кем-то еще. В обоих вариантах сообщение отбрасывается, опционно Боб может попытаться уведомить об этом Алису. |
/p> В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи.
Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту).
Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения. Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения.
В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца).
Важным принципом при анализе работы программ SET является идемпотентность – реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы.
XID
является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения. Его длина составляет 20 байт.
BrandID
представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product.
Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ.
Cert-PE
представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq.
Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers.
Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.
SignedData для вложения подписанной информации
EnvelopedData для инкапсуляции зашифрованных данных
EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма
DigestedData для инкапсуляции хэшированных или связанных данных
Тип SignedData из PKCS #7 проиллюстрирован на рис. 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.
Рис. 4.6.2.5. SignedData
Тип подписанного содержимого косвенно защищается включением в текст атрибута contentType (PKCS #9). Дайджест данных, который подписывается, также включает атрибут messageDigest. SignedData всегда содержит два аутентифицированных атрибута contentType и messageDigest.
Тип EnvelopedData из PKCS #7 проиллюстрирован на рис. 4.6.2.6.
Рис. 4.6.2.6. EnvelopedData
В пределах EnvelopedData допускается наличие нескольких EnvelopedData и только одно RecepientInfo.
Тип EncryptedData из PKCS #7 проиллюстрирован на рис. 4.6.2.7.
Рис. 4.6.2.7. EncryptedData
Тип DigestedData из PKCS #7 проиллюстрирован на рис. 4.6.2.8.
Рис. 4.6.2.8. DigestedData
Обработка сообщений
Базовыми процедурами протокола SET является посылка и прием сообщений. Процесс отправки сообщения представлен в таблице 4.6.2.4.
Таблица 4.6.2.4
. Отправление сообщения
| Шаг | Действие |
| 1 | Генерация сообщения SET |
| 2 | Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0) |
| 3 | Вложить код даты, включая время. |
| 4 | Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается. |
| 5 | Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса. |
| 6 | Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта |
| 7 | Вкладывается Message |
| 8 | Производится DER-кодирование вложенного сообщения |
| 9 | Сообщение передается на транспортный уровень |
Таблица 4.6.2.5.
Прием и обработка входного сообщения
| Шаг | Действие |
| 1 | Извлекается цифровой конверт сообщения |
| 2 | Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode. |
| 3 | Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений |
| 4 | Произвести DER-декодирование сообщения |
| 5 |
Если сообщение содержит SignedData, произвести следующее: Актуализовать системный кэш с учетом полученных CRL. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов Проверить подпись сообщения |
| 6 | Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData |
| 7 | Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается. |
| 8 | Обработать сообщение |
| 9 | Актуализовать системный журнал с учетом состояния транзакции |
/p> Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:
Контроль сертификатов X.509
Контроль сертификатов SET
Обработку CRL (Certificate Revocation List)
Обработку BrandCRLIdentifier (BCI)
На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6.
Таблица 4.6.2.6
. Верификация сертификатов
| Шаг | Действие |
| 1 | Верифицировать каждый сертификат в цепи согласно правилам X.509 |
| 2 | Проверить то, что расширения KeyUsage, CertificatePolicies, PriviteKeyUsage и AuthorityKeyIdentifier находятся в согласии c Х.509. |
| 3 |
Если получено новое значение BCI: а. Проверить его подпись, используя сертификат CRL центра сертификации платежной системы б. Проверить, что BrandName в BCI соответствует тому, что проверено в цепочке сертификации в. Проверить, что дата NotAfter меньше текущей даты г. Проверить SequenceNum. Если оно больше чем SequenceNum из кэша BCI запомнить BCI и проверить, что все CRL, содержащиеся в BCI находятся в кэше CRL. Запомнить любой CRL, который пока нет в кэше |
| 4 | Провести верификацию для каждого нового полученного CRL, |
| 5 | Проверить каждый сертификат |
4.6.2.1.1. Оттиски (Thumbprints)
Оттиски определяются путем вычисления хэш функции SHA-1, следуя кодировке DER ASN.1 структур:
UnsignedCertificate
UnsignedCertificateRevocationList
UnsignedBrandCRLIdentifier
Оттиск является тем же самым хэшем, который используется для подписи, верификации, CRL или BCI. Оттиски посылаются в сообщениях-запросах SET и могут игнорироваться получателем. Отправитель не обязан посылать все оттиски для всех сертификатов, CRL и BCI, имеющимся в его кэше, а только те, которые имеют отношение к конкретной паре сообщений запрос/отклик. Например, программа продавца не обязана посылать оттиски для всех держателей карт или всем платежным системам. Процедура отправки оттиска представлена в таблице 4.6.2.7.
Таблица 4.6.2.7.
Посылка оттиска
| Шаг | Действие |
| 1 | Инициализировать буфер для запоминания оттисков |
| 2 |
Добавить оттиск (хэш): Для каждого сертификата, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому сертификату. Для каждого CRL, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому CRL. Для каждого BCI, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому BCI. |
| 3 | Присылается результат работы шага 2. |
Таблица 4.6.2.8
. Обработка оттисков получателем
| Шаг | Действие |
| 1 | Инициализировать буфер для запоминания оттисков |
| 2 |
Для каждого из них: Для сертификата, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить соответствует ли оттиск (хэш) сертификата одному из полученных в сообщении-запросе. Если соответствие найдено, сертификат в кэше удаленной системы существует и его не нужно включать в отклик. Если соответствия нет или список пуст, то включить сертификат в сообщение отклик. Для CRL, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствие имеется, то CRL в кэше удаленной системы существует и его не следует помещать в отклик. Если соответствия нет или список пуст, то данное CRL включается в отклик. Для BCI, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли CRL-оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствия нет или список пуст, то данное CRL включается в отклик. |
| 3 | Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике. |
/p> Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.
| Шаг | Действие |
| 1 | Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t |
| 2 | Добавить результат шага 1 в группу t |
| 3 | Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2 |
| 4 | Послать результат работы шага 3 |
Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования – RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9.
Таблица 4.6.2.9.
Процедура асимметричного шифрования
| Шаг | Действие |
| 1 | Инициализировать и загрузить информационные поля, зависимые от типа сообщения |
| 2 | Преобразовать информационные поля, подлежащие шифрованию, в формат DER |
| 3 | Сформировать новый ключ DES |
| 4 | Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC. |
| 5 | Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4. |
| 6 | Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт) |
| 7 | Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3. |
| 8 | Применить OAEP для буфера цифрового конверта |
| 9 | Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r |
| 10 | Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9 |
| 11 | Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5 |
| 12 | Прислать результат шага 11 |
/p> Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10.
Таблица 4.6.2.10
. Асимметричное шифрование с гарантией целостности
| Шаг | Действие |
| 1 | Инициализировать и загрузить информационные поля, зависимые от типа сообщения |
| 2 | Преобразовать информационные поля, подлежащие шифрованию, в формат DER |
| 3 | Вычислить хэш SHA-1 результата шага 2 |
| 4 | Сформировать новый ключ DES |
| 5 | Зашифровать результат работы шага 2, используя ключ DES из шага 4. Используется режим DES-CBC. |
| 6 | Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма DES и добавить эту информацию к результату шага 5. |
| 7 | Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт) |
| 8 | Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 4 и хэша, вычисленного на шаге 5. |
| 9 | Применить OAEP для буфера цифрового конверта |
| 10 | Зашифровать результат шага 9, используя асимметричный общедоступный ключ объекта r |
| 11 | Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 10 |
| 12 | Инициализировать буфер PKCS#7 и положить туда результат шага 11 и 6 |
| 13 | Прислать результат шага 12 |
Таблица 4.6.2.11.
Процедура симметричного шифрования
| Шаг | Действие |
| 1 | Инициализировать и загрузить информационные поля, зависимые от типа сообщения |
| 2 | Преобразовать информационные поля, подлежащие шифрованию, в формат DER |
| 3 | Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC. |
| 4 | Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3. |
| 5 | Прислать результат шага 4 |
/p> Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования.
Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo.
Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7.
В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes
последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12.
Таблица 4.6.2.12.
Процедура формирования цифровой подписи
| Шаг | Действие |
| 1 | Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию |
| 2 | Преобразовать информацию, подлежащую подписанию в формат DER |
| 3 | Использовать результат шага 2 для инициализации компонента content из ContentInfo. |
| 4 | Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста |
| 5 | Вычислить дайджест сообщения, используя SHA-1 для результата шага 3 |
| 6 | Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов |
| 7 | Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута – значением дайджеста, вычисленного на этапе 5 |
| 8 | Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData |
| 9 | Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData |
| 10 | Если тип сообщения требует двух подписей, повторить шаги с 4 по 9 |
Таблица 4.6.2.13.
Процедура ключевого хэширования
| Шаг | Действие |
| 1 | Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36 |
| 2 | Установить opad равным буферу, содержащему 64 байта с кодами 0х5С |
| 3 | Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля. |
| 4 | Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad |
| 5 | Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4 |
| 6 | Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора |
| 7 | Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad |
| 8 | Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7 |
| 9 | Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора |
| 10 | Прислать результат работы шага 9 |
/p> Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP.
Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора.
Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14.
Таблица 4.6.2.14.
Процедура вычисления дайджеста сообщения.
| Шаг | Действие |
| 1 | Установить B равным адресу группы t, для которой вычисляется дайджест |
| 2 | Установить L равным длине группы t |
| 3 | Инициализировать 160-битный буфер для хранения хэша SHA-1 |
| 4 | Вычислить хэш SHA-1 для буфера, используя B и L |
| 5 | Положить результат шага 4 в поле digest DigestedData |
| 6 | Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm |
| 7 | Установить значение версии равным нулю |
Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными.
Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15.
Таблица 4.6.2.15
. Описание алгоритма OAEP
| Шаг | Действие |
| 1 | Подготовить дополнительные данные, как это описано в формате сообщения |
| 2 | Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию |
| 3 | Сформировать новый случайный ключ для DES-шифрования регулярной части данных |
| 4 | Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block). |
| 5 | Взять байт, содержащий код 0х03 (тип блока – BT), семь байтов нулей (байты верификации – V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB |
| 6 | Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1 |
| 7 |
Вычислить А=DB A H1(E-Salt) |
| 8 |
Осуществить присвоение B= E-Salt A H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1 |
| 9 | Присвоить I случайное значение, не равное 0х00 или 0х80 |
| 10 | Зашифровать полученный блок R с помощью RSA |
В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.
Рис. 4.6.2.9. Диаграмма работы OAEP
Обработка ошибок
Каждому сообщению-запросу должно соответствовать сообщение-отклик. Сообщения об ошибках могут соответствовать как запросам, так и откликам. Сообщение об ошибке указывает, что приславший его не смог разобрать формат полученного запроса или отклика, или при обработке потерпели неудачу верификационные тесты. Не следует путать отрицательный отклик с сообщением об ошибке. Сообщение об ошибке посылается при невозможности обработать входное сообщение. Сообщение Error не посылается, например, при непрохождении аутентификации. Причиной сигнала ошибки может быть искажение пакета при транспортировке по локальной сети или через Интернет, нелегальные значения полей сообщения или протокольные искажения.
Для выявления сообщений-дубликатов достаточно использовать открытый текст, содержащийся в цифровом конверте сообщения. Реакция получателя на сообщение-дубликат зависит от свойств идемпотентности конкретного типа сообщения, от числа дубликатов, частоты их поступления и от того, кто является их отправителем.
Поврежденным сообщением считается такое, которое не может быть обработано. В норме такие сообщения не должны приходить, так как имеется контроль корректности пакетов на транспортном уровне и при обнаружении любых повреждений сообщение должно быть переслано повторно. Но если такое “невозможное событие” все-таки произойдет, будет послано сообщение Error, содержащие код типа ошибки и идентификатор сообщения, ее вызвавшего. Приложение никогда не посылает сообщение Error в ответ на другое сообщение Error. Сообщения, которые не являются протокольными для SET, просто игнорируются.
Если тэг типа сообщения равен 999 (указывая, что это сообщение об ошибке), приложение SET не должно ни при каких обстоятельствах посылать на него отклик. Когда приложение сталкивается с ошибкой, оно формирует Error-сообщение в следующей последовательности.
| Шаг | Действие |
| 1 |
Сформировать ErrorTBC следующим образом: Установить ErrorCode равным значению, указывающему на причину (см. табл. 4.6.2.16) Сформировать новый ErrorNonce Если ошибка случилась из-за того, что приложение не знает, как обрабатывать расширение сертификата или сообщения, занести в ErrorOID объектный идентификатор расширения. Если ошибка произошла из-за проблем с сертификатом, занести в ErrorThamb ThumbPrint сертификата Если ошибка является результатом неудачной верификации подписи, занести в ErrorThamb хэш сертификата ErrorMsg формируется следующим образом: заносится MessageHandler или все сообщение (но не более 20 килобайт). Выбор того, следует ли заносить все сообщение или только заголовок, оставляется на усмотрение разработчика. |
| 2 | Подписать сообщение Error, если имеется сертификат подписи |
| 3 | Вызвать формирование цифрового конверта и отправить сообщение |
/p> Для сообщения Error определены следующие поля
| Имя поля | Описание |
Error |
<Signed Error, UnsignedError > |
SignedError |
S(EE, ErrorTBS) |
UnsignedError |
ErrorTBS Неподписанная версия Error будет использоваться, если объект не имеет сертификата подписи |
ErrorTBS |
{ ErrorCode, ErrorNonce, [ErrorOID], [ErrorThumb], ErrorMsg} |
ErrorCode |
Цифровой код, определяющий условия ошибки (см. табл. 4.6.2.16) |
ErrorNonce |
Разовый код, который гарантирует, что подпись генерируется для трудно предсказуемых данных |
ErrorOID |
Объектный идентификатор неподдерживаемых критических расширений, вызвавших ошибку |
ErrorThumb |
Оттиск сертификата, который вызвал ошибку или хэш сертификата, если произошла ошибка верификации подписи |
ErrorMsg |
<MessageHeader, BadWrapper> |
MessageHeader |
Заголовок сообщения, которое вызвало ошибку |
BadWrapper |
Цифровой конверт сообщения, которое вызвало ошибку (не более 20 килобайт) |
Таблица 4.6.2.16.
ErrorCode
| Ошибка | Описание |
unspecifiedFailure |
Причина неудачи не фигурирует в списке стандартных ошибок |
messageNotSupported |
Этот вполне корректный тип сообщения не поддерживается получателем |
decodingFailure |
Произошла ошибка в процессе DER-кодирования сообщения |
invalideCertificate |
Сертификат, необходимый для обработки сообщения, некорректен. Поле ErrorThumb идентифицирует этот сертификат. |
expiredCertificate |
Время действия сертификата, необходимого для обработки сообщения, иссякло. Поле ErrorThumb идентифицирует этот сертификат. |
revokedCertificate |
Сертификат, необходимый для обработки сообщения, отозван. Поле ErrorThumb идентифицирует этот сертификат. |
missingCertificate |
Сертификат, необходимый для обработки этого сообщения, отсутствует в кэше сертификатов получателя. |
signatureFailure |
Цифровая подпись сообщения не может быть верифицирована |
badMessageHeader |
Заголовок сообщения не может быть обработан |
wrapperMsgMismatch |
Содержимое цифрового конверта сообщения не согласуется с внутренним содержимым сообщения. |
versionTooOld |
Номер версии сообщения слишком стар для получателя |
versionTooNew |
Номер версии сообщения слишком нов для получателя |
|
unrecognizedExtension |
Сообщение или сертификат содержит критическое расширение, которое получатель не может обработать. Поле ErrorOID идентифицирует расширение. Если расширение присутствует в сертификате, поле ErrorThumb идентифицирует сертификат |
messageTooBig |
Сообщение слишком длинно для получателя |
signatureRequired |
Неподписанная версия сообщения неприемлема |
messageTooOld |
Дата сообщения слишком далеко в прошлом для получателя |
messageTooNew |
Дата сообщения слишком близка для получателя |
thumbsMismatch |
Оттиск, посланный в неподписанном запросе, не согласуется с тем, что прислано запрашивающей стороне |
unknownXID |
Получен неизвестный RRPID |
challengeMismatch |
Вызов, посланный в запросе, не согласуется с вызовом в отклике |
/p> Так как сообщения Error могут посылаться, в том числе и в ответ на отклик, возникает проблема при работе с протоколами, базирующимися на алгоритмах запрос-отклик (например, HTTP). В этом случае сообщение об ошибке может посылаться в качестве запроса, на который необязательна посылка отклика. На нижележащем протокольном уровне при этом может происходить таймаут.
Работа с сертификатами
В работе с сертификатами участвуют девять субъектов. Иерархия этих субъектов представлена на рис. 4.6.2.10. Верхнюю позицию в иерархии занимает корневой центр сертификации. Корневой сертификат следует требованиям документа X.509 (версия 3) с некоторыми расширениями, вводимыми протоколом SET. Прежде чем система будет развернута, должны быть проделаны следующие операции:
Нужно сформировать пару #1 корневых ключей R1
Сгенерировать сертификат для корневого ключа #1 (C1)
Сформировать пару #2 корневых ключей R2
Вычислить оттиск (хэш – H2) общедоступной составляющей R2
С1 рассылается при развертывании системы и является самоподписываемым. Корневой сертификат SET доставляется приложению с помощью протокола запроса сертификата и платежного протокола. Начальное значение корневого сертификата, его общедоступный ключ или хэш общедоступного ключа могут быть доставлены и программой приложения SET. Как только приложением получен новый корневой сертификат, оно проверяет через расширение HashedRootKey связь с предыдущим корневым сертификатом.
Когда приходит время заменить корневой сертификат R1, производятся следующие операции:
Вычисляется общедоступная часть корневого ключа #3 (R3)
Определяется оттиск R3 (хэш H3)
Формируется сертификат корневого ключа #2 (C2 – содержит H3)
Новый корневой сертификат рассылается с использованием SET-сообщений или методик HTTP, FTP или SMTP. Приложение SET проверяет подпись, используя R2, вычисляет хэш R2 и сравнивает его с H2, полученным из расширения в С1.
Рис. 4.6.2.10. Иерархия субъектов сертификации
Из списка этих субъектов один является опционным, это GCA (Геополитический центр сертификации - Geo-Political Certificate Authority). Проверка сертификатов производится строго в соответствии с данной иерархической схемой. Доступ к корневому центру сертификации производится крайне редко, только в случае получения нового сертификата платежной системы или при обновлении корневого сертификата. При взаимодействии с ним привлекается в максимально возможной мере аппаратный контроль. Если произойдет раскрытие секретного ключа платежной системы, то RCA сформирует и разошлет новый список отмененных сертификатов CRL (Certificate Revocation List).
BCA являются независимыми для каждой платежной системы и реализуются практически теми же мерами безопасности, как и RCA. Эти центры служат для формирования и рассылки геополитических и/или сертификатов владельцев карты, продавцов или платежных центров, размещенных ниже по иерархии. Они также ответственны за обновление и рассылку списков CRL и BCI, содержащие все CRL платежной системы.
Геополитические центры сертификации (являются опционными) позволяют платежным системам перераспределять ответственность между отдельными географическими и политическими регионами. Эти центры ответственны за формирование и рассылку соответствующих региональных CRL.
Центры сертификации владельцев карт (ССА) формируют по запросу и отсылают сертификаты владельцам платежных карт. Запрос сертификата может быть послан через WEB или по электронной почте. ССА поддерживают взаимоотношения с эмитентами карт для сертификации счетов владельцев карт. ССА также занимаются рассылкой CRL, сформированных RCA, BCA, GCA и центров сертификации платежных центров. Функции CCA может выполнять центр платежной системы, эмитента карты или какой-то иной субъект, который отвечает требованиям конкретной платежной системы.
Центр МСА ответственен за рассылку сертификатов продавцам. Получатели (Acquirers) проверяют и одобряют запросы сертификатов продавца до их выдачи центром MCA.
Центр PCA служит для выдачи сертификатов для платежных центров. Их функции, также как и в случае CCA, могут выполняться центрами платежной системы, получателя и т.д.
Любой центр сертификации выполняет следующие функции:
Формирование и выдача сертификата
Обновление сертификатов
Контроль работоспособности сертификатов и удаление непригодных
Формирование сертификатов осуществляется различными методами, зависящими от типа объекта. Для владельцев карты формируются только сертификаты подписи, для продавцов и платежных центров формируются сертификаты подписи и шифрования.
Сертификаты для владельцев карт формируются центрами CCA. Выпуск сертификата держателя карты включает в себя следующие обмены между держателем карты и CCA (см. также рис. 4.6.2.2).
Владелец карты посылает запрос сертификата
ССА производит шифрование сертификата для защиты передачи номера платежной карты в ССА
Владелец шифрует номер своей карты, используя сертификат ССА, и посылает результат в ССА
ССА откликается посылкой формы для регистрации сертификата карты
Владелец карты заполняет форму, которая включает в себя его общедоступный ключ, и посылает форму в ССА для регистрации
ССА верифицирует полученную регистрационную информацию с привлечением эмитента карты и генерирует сертификат, подписывает его и посылает владельцу карты.
Для продавцов сертификаты формируются в центрах MCA. Перед выпуском сертификата продавца запрос верифицируется банком продавца (получатель – acquirer) или центром управления платежной системы. Сертификат получается продавцом в результате последовательности следующих операций.
Продавец посылает запрос сертификата в МСА.
МСА откликается посылкой регистрационной формы.
Продавец заполняет форму и посылает ее и свой общедоступный ключ в МСА для обработки.
Банк продавца или центр управления платежной системы проверяет запрос продавца и МСА генерирует, подписывает и посылает сертификат продавцу.
Сертификаты платежного центра формируются и присылаются центром PCA. Процедура генерации сертификата сходна с вариантом продавца. Банк продавца верифицирует запрос сертификата платежного центра и авторизует генерацию сертификата в РСА. Сертификаты центров сертификации формируются вышестоящими по иерархии узлами. Обновление любых сертификатов производится периодически и следует тем же алгоритмам, что и формирование совершенно нового сертификата. Регистрационная форма при обновлении сертификата может содержать существенно меньше информации.
Аннулирование сертификата может производиться по разным причинам, например, из-за реального или кажущегося раскрытия секретного ключа, из-за изменения регистрационной информации или по причине истечения срока пригодности. При аннулировании идентификатор и некоторые другие характеристики сертификата заносятся немедленно в список CRL. Последний сразу подлежит рассылке всем субъектам, которые могут использовать этот сертификат.
При выполнении любой операции в рамках протокола SET производится проверка всех сертификатов, образующих иерархическую цепочку (см. рис. 4.6.2.11), начиная от конечного объекта (ЕЕ) до корневого (Root). Стрелки означают, чей сертификат использовался для подписи. Таким образом, каждый сертификат связан с сертификатом подписи субъекта его сформировавшего.
Рис. 4.6.2.11. Иерархия проверок
Основной протокол
Далее рассматривается протокол и обработка откликов владельца карты, продавца или платежного центра (конечный объект – EE), а также получение подписей и/или сертификатов Х.509 шифрования данных от СА (Certificate Authority). Протокол определяет процедуры получения первого сертификата или обновления предшествующего.
Прежде чем запросить сертификат владелец карты должен выполнить следующее:
Получить счет в одной из платежных систем, например, в VISA или MasterCard.
Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа. Понятно, что местом его хранения не может быть оперативная память, да и дисковые накопители вряд ли можно считать приемлемым местом записи, если хотя бы теоретически к ним может быть получен доступ.
Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации владельца карты. Это должно быть сделано в соответствии с требованиями эмитента карты.
Иметь URL или электронный почтовый адрес для связи с ССА.
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
Продавец должен иметь следующее, прежде чем посылать запрос сертификата:
Идентификатор, присланный получателем (Acquirer – банк продавца)
Иметь возможность формировать общедоступный и секретные ключи. Обеспечить безопасное хранение секретного ключа.
Программа продавца должна иметь определенную информацию, объем и характер которой согласуется с банком продавца.
URL или электронный почтовый адрес для связи с MCA.
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
Расчетный центр должен обзавестись следующим, прежде чем посылать запрос сертификата:
Возможностью формировать пары ключей (секретый/общедоступный) и местом их надежного храниения.
Получить банковский идентификационный номер BIN (Bank ID)
Программа владельца карты должна иметь определенную информацию, которая может быть использована для идентификации и аутентификации платежного центра. Объем и характер этой информации согласуется с банком продавца.
Иметь URL или электронный почтовый адрес для связи с PCA
Обзавестись прикладной программой (например, броузером), поддерживающей протокол SET.
После того как приложение запущено, стартуют сертификационные обмены между владельцем карты и CCA, между продавцом и MCA, а также между платежным центром и PCA. В результате участники получают необходимые сертификаты подписи и шифрования. Так взаимодействие владельца карты и ССА предполагает следующие обмены:
Приложение владельца карты посылает CardCInitReq CCA. При этом используется идентификатор платежной системы или идентификатор, полученный из стартового сообщения.
ССА посылает приложению SET сообщение CardCInitRes.
Приложение владельца карты посылает ССА сообщение RegFormReq.
ССА отправляет сообщение RegFormRes, содержащее регистрационную форму и формулировку общих требований.
Приложение владельца карты заполняет регистрационную форму, заносит свой общедоступный ключ и сертификат, подлежащий обновлению (если имеется) в CertReq и посылает его ССА.
ССА формирует сертификат, включает его в CertRes и посылает владельцу карты.
Функционирование приложения продавца и платежного центра имеет свою специфику:
Приложение SET посылает сертификационному центру СА сообщение Me-AqCInitReq, при этом используется BIN и идентификатор продавца, полученные от системного администратора продавца или платежного центра.
СА посылает приложению SET сообщение Me-AqCInitRes, содержащее регистрационную форму и формулировку общих требований.
Приложение SET отображает эту форму и требования. Пользователь должен заполнить регистрационную форму и согласиться с предлагаемыми требованиями.
Приложение SET включает в CertReq заполненную форму, новый общедоступный ключ и сертификат, подлежащий обновлению (если он имеется) и посылает это все СА.
СА формирует сертификат, включает его в CertRes и посылает продавцу или платежному центру.
Схемы таких обменов для получения нового или обновления старого сертификатов представлены на рис. 4.6.2.12 и 4.6.2.13. Логика обменов для получения сертификата владельцем карты при начальной регистрации была показана на рис 4.6.2.12.
Рис. 4.6.2.12. Схема обмена сообщениями при получении сертификата между владельцем карты и ССА
Если ЕЕ уже имеет регистрационную информацию, обмены CardCInitReq/Res и RegFormReq/Res могут быть опущены. При работе через WWW используется во всех случаях полный перечень обменов. После того как приложение SET инициализировано, владелец карты посылает ССА сообщение CardCInitReq, указывающее через оттиски на сертификаты, CRL и BrandCRLIdentifier, которые содержаться в его кэше сертификатов. ССА реагирует посылкой сообщения CardCInitRes, содержащего любые сертификаты, CRL и BrandCRLIdentifier, которые потребуются владельцу карты для верификации подписи, а также сертификат шифрования, используемый для последующих сообщений.
Приложение SET формирует сообщение CardCInitReq следующим образом.
| Шаг | Действие |
| 1 | Генерируется RRPID |
| 2 | Генерируется LID-EE |
| 3 | Формируется новый случайный Chall-EE |
| 4 | Копируется BrandID, который запомнен или получен в инициализирующем сообщении |
| 5 | Опционно заполняется поле Thumbs, которое содержит оттиски для каждого CRL, сертификатов SET, BrandCRLIdentifier и корневой сертификат, резидентный в кэше владельца карты |
| 6 | Формируется цифровой конверт сообщения, чтобы послать CardCInitReq центру ССА |
Таблица 4.6.2.17. Структура сообщения CardCInitReq
CardCInitReq |
{RRPID, LID-EE, Chall-EE, BrandID, [Thumbs]} |
RRPID |
Идентификатор пары запрос/отклик |
LID-EE |
Локальный ID, сформированный для системы владельца карты |
Chall-EE |
Вызов владельца карты по поводу пригодности подписи, адресованный ССА |
BrandID |
Идентификатор платежной системы для запрошенного сертификата |
Thumbs |
Список оттисков сертификатов (включая корневой), CRL и BrandCRLIdentifier, которые хранятся в данный момент владельцем карты |
/p> ССА, получив CardCInitReq, выполнит следующие операции:
| Шаг | Действие |
| 1 | Получить CardCInitReq из сообщения Receive |
| 2 | Проверить, что RRPID в CardCInitReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается сообщение об ошибке с кодом ErrorCode= unknownRRPID |
| 3 | Запомнить список откликов, LID-EE, Chall-EE и RRPID, которые должны быть использованы в CardCInitRes |
| Шаг | Действие |
| 1 |
Сформировать структуру данных CardCInitResTBS, для этого: Скопировать RRPID, LID-EE и Chall-EE, полученные из сообщения CardCInitReq Сформировать опционно LID-CA Заполнить CAEThumb оттиском сертификата шифрования данных CCA Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, занести BrandCRLIdentifier Скопировать список оттисков из CardCInitReq |
| 2 |
Подписать DER-кодированный массив кодов CardCInitResTBS, установить тип содержимого SigneadData равным id-set-content- CardCInitResTBS. Включить в SigneadData любые сертификаты, CRL или BrandCRLIdentifier, которые отсутствуют в списке оттисков. |
| 3 | Сформировать цифровой конверт сообщения и послать сообщение CardCInitRes владельцу карты |
CardCInitRes |
S(CA, CardCInitResTBS) |
CardCInitResTBS |
{RRPID, LID-EE, Chall -EE, [LID-CA], CAEThumb, [BrandCRLIdentifier], [Thumbs]} |
RRPID |
Идентификатор пары запрос/отклик |
LID-EE |
Копируется из CardCInitReq |
Chall-EE |
Копируется из CardCInitReq |
LID-CA |
Локальный ID. Генерируется системой CCA или для нее |
CAEThumb |
Оттиск сертификата ключевого обмена CCA, котоый владелец карты должен использовать для шифрования RegFormReq |
BrandCRLIdentifier |
Смотри секцию описания BrandCRLIdentifier |
Thumbs |
Копируется из CardCInitR |
/p> Приложение владельца карты обрабатывает сообщение CardCInitRes в следующей последовательности:
| Шаг | Действие |
| 1 | Получить CardCInitRes из входного сообщения (Receive) |
| 2 | Проверить, что RRPID соответствует тому, что был послан в CardCInitReq и тому, который получен в цифровом конверте сообщения CardCInitRes. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным unknownRRPID |
| 3 | Проверить, что полученный список оттисков соответствует тому, что был послан в сообщении CardCInitReq. Если соответствия нет, посылается сообщение об ошибке с кодом ErrorCode равным thumbsMismatch |
| 4 | Проверить, что полученный Chall-EE равен посланному в CardCInitReq. Если равенство отсутствует, посылается сообщение об ошибке с кодом ErrorCode равным challengeMismatch. |
| 5 | Запомнить LID-CA (если этот элемент был включен) для последующей записи в RegFormReq. Проверить, что полученный Chall-EE равен посланному в CardCInitReq. |
| 6 | Проверить, что приложение владельца карты поддерживает один из алгоритмов, перечисленных в туннельном расширении сертификата шифрования CA. Если приложение владельца карты не поддерживает ни одного общего с СА алгоритма, следует уведомить об этом пользователя и прервать дальнейшую обработку сообщения СА. |
| Шаг | Действие |
| 1 |
Сформировать RegFormReqData согласно следующему формату: Сформировать новый RRPID Скопировать LID-EE, посланный в CardCInitReq Сформировать новый Chall-EE2 Если такой элемент был включен в CardCInitRes, скопировать LID-CA Заполнить RequestType согласно таблице 4.6.2.19, где представлены коды поля RequestType регистрационной формы владельца карты Заполнить поле языка (Language) Опционно ввести список оттисков для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентных для кэша оттисков владельца карты (если таковой имеется). |
| 2 |
Сформировать структуру RegFormReqTBE: Ввести ReqFormReqData Заполнить поле PANOnly, используя PAN и ExNonce. В PAN не используется заполнитель. Сформировать хэш SHA-1 для DER-кодированного PANOnly. Установить код типа содержимого digestedData равным id-set-content-PANOnly |
| 3 |
Оформить поле данных, подлежащих дополнительному шифрованию: Заполнить PAN. Если PAN имеет длину менее 19 байт, дополнить его до 19 байт Для маскирования PAN сгенерировать новый EXNonce |
| 4 |
Зашифровать данные, используя оператор EXH со следующими параметрами: RegFormReqTBE в качестве данных, подлежащих шифрованию, и типом contentType данных Envelopeddata равным id-set-content-RegFormReqTBE и Результатом шага 3 в качестве данных, подлежащих шифрованию Для шифрования используется сертификат идентифицированный CAEThumb в CardCInitRes |
| 5 | Вложить результат в цифровой конверт комбинированного сообщения и послать RegFormReq в центр СА |
/p> Структура сообщения RegFormReq представлена в таблице 4.6.2.18.
Таблица 4.6.2.18
. Структура RegFormReq
RegFormReq |
EXH(CA, RegFormReqData, PANOnly) |
RegFormReqData |
{RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]} |
PANOnly |
Структуру смотри в табл. ниже |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из CardCInitRes |
Chall-EE2 |
Вызов ЕЕ, имеющий целью обновление подписи СА |
LID-CA |
Копируется из CardCInitRes |
RequestType |
Смотри табл. 4.6.2.19 |
Language |
Предпочтительный язык последующего текста |
Thumbs |
Списки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты |
Имя поля |
Описание |
PAN |
Номер платежной карты владельца |
EXNonce |
Случайное число, используемое для маскирования PAN |
Таблица 4.6.2.19
. Значения кодов RequestType
| Тип запроса | Только сертификат подписи | Только сертификат шифрования | Оба сертификата |
| Начальный запрос владельца карты | 1 | 2* | 3* |
| Запрос обновления владельца карты | 10 | 11* | 12* |
Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.
| Шаг | Действие |
| 1 | Извлечь RegFormReq из входного сообщения |
| 2 | Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя. |
| 3 | Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка. |
| 4 | Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID |
| Шаг | Действие |
| 1 |
Сформировать RegFormTBS в соответствии со следующей процедурой: Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqData Если в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса. Сгенерировать новый Chall-CA Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier. Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде: Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и Language Включить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено. Опционно добавляется URL для отображения логотипа платежной системы или карты. CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes. Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData: Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания. |
| 2 | Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS. |
| 3 | Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes |
/p> Структура сообщения RegFormRes представлена в таблице 4.6.2.20.
Таблица 4.6.2.20
. Структура RegFormRes
RegFormRes |
S(CA, RegFormResTBS) |
RegFormResTBS |
{RRPID, LID-EE, Chall-EE2,[LID-CA], Chall-CA, [CAEThumb], RequestType, RegFormOrReferral, [BrandCRLIdentifier], [Thumbs]} |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из RegFormReq |
Chall-EE2 |
Копируется из RegFormReq |
LID-CA |
Локальный ID. Формируется для системы СА. |
Chall-CA |
СА обращение по поводу пригодности сертификата запрашивающей стороны |
CAEThumb |
Оттиск сертификата ключевого обмена, который должен использоваться для шифрования CertReq. Если это поле отсутствует, используется сертификат, идентифицированный в CardCIntRes. |
RequestType |
Смотри табл. 4.6.2.19 |
RegFormOrReferral |
Смотри табл. 4.6.2.21 |
BrandCRLIdentifier |
Смотри описание в разделе о BrandCRLIdentifier ниже. |
Thumbs |
Копируется из RegFormReq |
Таблица 4.6.2.21
. Структура поля RegFormOrReferral
RegFormOrReferral |
<RegFormData, ReferralData> |
RegFormData |
{[RegTemplate], PolicyText} |
ReferralData |
{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq} |
RegTemplate |
{RegFormID, [BrandLogoURL], [CardLogoURL], RegFieldSeq} |
PolicyText |
Заявление, которое должно быть отображено в системе отправителя запроса вместе с RegTemplate |
Reason |
Заявление, связанное с запросом и отображаемое в системе отправителя запроса |
ReferralURLSeq |
{ReferralURL +} Опционные URL ссылок, перечисленные в порядке важности |
RegFormID |
Идентификатор, присвоенный СА |
BrandLogoURL |
URL базовой страницы расчетной системы |
CardLogoURL |
URL базовой страницы финансовой организации |
RegFieldSeq |
{RegField +} |
ReferralURL |
URL альтернативного СА для обработки запросов сертификатов для данного объекта |
RegField |
{[FieldId], FieldName, [FieldDesc], [FieldLen], FieldRequired, FieldInvisible} |
FieldID |
Идентификаторы объекта для полей регистрационной формы |
FieldName |
Одно или более имен полей, которые должны быть отображены в качестве меток для заполнения формы; текст записывается на языке, определенном в RegFormReq или Me-AqCInitReq |
FieldDesc |
Описание содержимого поля на языке, заданном в RegFormReq или Me-AqCInitReq; содержит дополнительную информацию для использования в случае, когда владелец карты запросит помощи при заполнении формы |
FieldLen |
Максимальная длина поля |
FieldRequired |
Булево значение, указывающее на необходимость ввода (должен ли поле заполнить владелец карты или оно будет заполнено приложением) (невидимое поле) |
FieldInvisible |
Булево значение, указывающее на то, что поле не должно отображаться пользователю; приложение должно заполнить FieldValue, основываясь на FieldID, или оставить его пустым |
/p> Приложение владельца карты обрабатывает сообщение RegFormRes следующим образом:
| Шаг | Действие |
| 1 | Получить RegFormRes из входного сообщения |
| 2 | Проверить подпись. Если подпись некорректна, отправить сообщение об ошибке с ErrorCode равным signatureFailure. |
| 3 | Получить RRPID, RequestType, LID-EE, Chall-EE2, CAEThumb из RegFormTBS |
| 4 | Проверить, что RRPID является тем же самым, что и идентификатор, записанный в цифровом конверте сообщения, и совпадет с кодом, присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным unknownRRPID. |
| 5 | Проверить, что RequestType, LID-EE и Chall-EE2 идентичны присланным в RegFormReq. Если совпадения нет, отправить сообщение об ошибке с ErrorCode равным challengeMismatch. |
| 6 | Если был включен CAEThumb, запомнить соответствующий сертификат шифрования, использованный для шифрования CertReq. |
| 7 | Проверить, что полученные оттиски, соответствуют посланным в сообщении CardCInitReq. Если соответствия нет, отправить сообщение об ошибке с ErrorCode равным thumbsMismatch. |
| 8 |
Если в RegFormTBS включены данные RegFormData то: Запоминается LID-CA Прежде чем приложение SET сформирует CertReq, отображается текст общих требований и необходимый отклик пользователя Отображаются видимые поля регистрационной формы и приглашение для заполнения их пользователем. Если RegFormRes содержит URL, отображаются логотипы платежной системы или эмитента карты. Заполняются видимые поля регистрационной формы. Если поле является необходимым, а приложение не может его заполнить, оно остается пустым, а остальная часть формы заполняется и посылается обычным порядком. После того как пользователь завершил ввод, формируется сообщение CertReq. |
| 9 |
Если в RegFormResTBS включено поле ReferralData то: Отображается причина (Reason) Если включено ReferralLoc, отображаются URL или электронный адрес из ReferralLoc CertReq не формируется. Протокол переходит к формированию CardCInitReq |
Рис. 4.6.2.13. Схема обмена сообщениями при получении сертификата между продавцом и MCA или между платежным центром и PCA
При получении Me-AqCInitRes программа конечного пользователя (ЕЕ) может послать сообщение CertReq, содержащее заполненную форму. Процедура формирования Me-AqCInitReq включает в себя следующие операции:
| Шаг | Действие |
| 1 | Сформировать новый RRPID |
| 2 | Сформировать новый LID-EE |
| 3 | Сформировать новый случайный код Chall-EE |
| 4 | Занести BrandID, который хранится в приложении или получен в стартовом сообщении |
| 5 | Заполнить поле RequestType |
| 6 | Заполнить поле Language (язык) |
| 7 | Опционно создать оттиски для каждого CRL, сертификата, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше (если имеются) |
| 8 | Если ЕЕ (конечным пользователем) является продавец, заполнить поля BIN и ID продавца. В противном случае BIN получателя и его рабочий ID. |
| 9 | Сформировать цифровой конверт и послать сообщение Me-AqCInitReq СА. |
Таблица 4.6.2.22
. Формат Me-AqCInitReq
Me-AqCInitReq |
{RRPID, LID-EE, Chall-EE, RequestType, IDData, BrandID, Language, [Thumbs]} |
RRPID |
ID пары запрос/отклик |
LID-EE |
Локальный ID; формируется ЕЕ-системой или для нее |
Chall-EE |
Обращение EE к СА по поводу пригодности подписи |
RequestType |
Смотри табл. 4.6.2.24 |
IDData |
См. табл. 4.6.2.23 |
BrandID |
BrandID запрошенного сертификата |
Langauage |
Желательный язык последующих текстов |
Thumbs |
Список оттисков сертификатов, CRL и BrandCRLIdentifier, хранимых ЕЕ |
Таблица 4.6.2.23
. Формат IDData
IDData |
<MerchantAcquirerID, AcquirerID> (только для продавца и получателя) |
MerchantAcquirerID |
{MerchantBIN, MerchantBIN} |
AcquirerID |
{AcquirerBIN, [AcquirerBusinessID]} |
MerchantBIN |
Идентификационный номер банка для обработки транзакции продавца в его банке (Acquirer) |
MerchantID |
Идентификатор продавца, присвоенный ему его банком (Acquirer) |
AcquirerBIN |
Идентификационный номер банка для Acquirer (BIN получателя) |
AcquirerBusinessID |
Рабочий идентификационный номер банка продавца |
/p>
Таблица 4.6.2.24
. Значения RequestType для продавца и платежного центра
| Тип запроса | Только сертификат подписи | Только сертификат шифрования |
Оба сертификата |
| Начальный для продавца | 4 | 5 | 6 |
| Начальный для расчетного центра | 7 | 8 | 9 |
| Обновление для продавца | 13 | 14 | 15 |
| Обновление для расчетного центра | 16 | 17 | 18 |
| Шаг | Действие |
| 1 | Выделяеть Me-AqCInitReq из входного сообщения |
| 2 | Проверяеть, что RRPID из цифрового конверта сообщения совпадает с полученным в Me-AqCInitReq. Если это не так, формируется сообщение об ошибке с errorCode unknownRRPID. |
| 3 | Запоминается RRPID, LID-EE, Chall-EE, BrandID, Language, Thumbs и IDData |
| Шаг | Действие |
| 1 |
Сформировать сообщение Me-AqCInitResTBS: Скопировать RRPID, LID-EE и Chall-EE из Me-AqCInitReq Опционно сгенерировать LID-CA для данного вида запроса обслуживания Сгенерировать новый Chall-CA Если регистрационная форма продавца или платежного центра доступна для BIN, языка и RequestType, то: Заполнить поле RegFormData, используя RegTemplate и PolicyText, соответствующие Requesttype, BIN и Language Опционно включить URL для отображения логотипа платежной системы и/или карты Включить RegFormID и RegFieldSeq. При обновлении RegFieldSeq может быть опущено. Если СА посредством AcctData аутентифицирует продавца или расчетный центр, заполнить поле AcctDataField, указывая наименование данных, подлежащих вводу, описание, их длину и будут ли данные вводиться ЕЕ (конечным пользователем). Если соответствующая форма для продавца или расчетного центра не доступна, заполняется поле ReferralData: Включить причину отказа обслуживания, которая будет отображена для продавца или расчетного центра Опционно включить в ReferralLoc электронный адрес и/или URL, где пользователь может получить дополнительную информацию, об отказе обслуживания. Включить оттиск сертификата шифрования CA, CAEThumb. Если BrandCRLIdentifier в полученном Me-AqCInitReq не специфицирован, ввести BrandCRLIdentifier. Скопировать список оттисков (Thumbs) из Me-AqCInitReq Скопировать RequestType, полученный в Me-AqCInitReq. |
| 2 | Подписать Me-AqCInitResTBS, установить тип содержимого SignedData равным id-set-content-Me-AqCInitResTBS. |
| 3 | Сформировать цифровой конверт и послать сообщение Me-AqCInitRes продавцу или расчетному центру. |
/p> MCA и PCA используют один и тот же шаблон регистрационной формы, идентичный ССА (см. табл. 4.6.2.25)
Таблица 4.6.2.25
. Шаблон регистрационной формы MCA и PCA
Me-AqCInitRes |
S(CA, Me-AqCInitResTBS) |
Me-AqCInitResTBS |
{RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]} |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из Me-AqCInitReq |
Chall-EE |
Копируется из Me-AqCInitReq |
LID-CA |
Локальный ID; генерируется СА системой или для нее |
Chall-CA |
СА обращение по поводу пригодности сертификата запрашивающей стороны |
RequestType |
Смотри табл. 4.6.2.24 |
RegFormOrReferral |
Смотри табл. 4.6.2.21 |
AcctDataField |
RegField ; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq |
CAEThumb |
Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq |
BrandCRLIdentifier |
Смотри раздел описания BrandCRLIdentifier ниже. |
Thumbs |
Копируется из Me-AqCInitReq |
следующим образом:
| Шаг | Действие |
| 1 | Получить Me-AqCInitRes из входного сообщения. |
| 2 | Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure. |
| 3 | Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType |
| 4 | Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID. |
| 5 | Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch. |
| 6 | Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch. |
| 7 |
Если в Me-AqCInitResTBS включено поле RegFormData то: Запомнить LID-CA и Chall-CA Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq. |
| 8 | После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq. |
| 9 |
Если в Me-AqCInitResTBS включено поле ReferrelData, то: Отображается причина Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq |
/p> Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq.
Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме.
Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме.
Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме.
Запрос сертификата (CertReq) содержит в себе:
Новые общедоступные ключи.
Обновляемые сертификаты (если таковые есть).
Заполненную регистрационную форму.
Информацию об аккоунте ЕЕ
Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,
Другие контрольные коды
Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа.
Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq.
ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА. Me-AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo.
Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.
| Шаг | Действие |
| 1 | Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата |
| 2 | Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования. |
| 3 | Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код – CardSecret. |
| 4 | Генерируется 160-битовый случайный код – EXNonce |
| 5 |
Формируется CertReqTBS: Генерируется RRPID Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType. Заполняется поле RequestData Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый. Генерируется новый Chall-EE3 Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения. Если ЕЕ является продавец карты или расчетный центр, то: заполняется поле IDData и, если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret. Сформировать EXNonce Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму. |
| 6 |
Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь. Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА. Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им. Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше. |
| 7 |
Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0. Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce. |
| 8 |
Данные укладываются в конверт с использованием техники EncX: Включить: Обработка а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS. Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату. Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи. Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL. Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS. b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes c. CertReqTBEX в качестве данных, подлежащих шифрованию Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX |
| 9 | Сформировать цифровой конверт и послать сообщение CertReq центру СА |
/p> Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:
| Шаг | Действие |
| 1 | Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи |
| 2 | Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования |
| 3 | Сгенерируется 160-битное случайное число - EXNonce |
| 4 |
Данные CertReqData формируются следующим образом: Генерируется RRPID Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем. Заполняется поле ReqestDate Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое. Генерируется новое Chall-EE3 Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется. Заполнить поле IDData Занести RegFormID, полученный из Me-AqCInitRes Занести новую или скорректированную форму RegForm Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА. Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению. Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты. |
| 5 |
Поместить данные в цифровой конверт, используя инкапсуляцию Enc: Включить: Обработка CertReqData в качестве информации, подлежащей подписыванию. То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS. Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату. Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи. Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData. Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE. Ключ DES в качестве данных, подлежащих дополнительному шифрованию Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes. CertReqTBE в качестве обычных данных, подлежащих шифрованию Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE. |
| 6 | Подготовить цифровой конверт и послать CertReq центру СА |
/p> Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26:
Таблица 4.6.2.26.
Формат CertReq
CertReq |
<EncX(EE, CA, CertReqData, AcctInfo), Enc(EE, CA, CertReqData)> Допускается инкапсуляция с двумя подписями. CertReqTBE и AcctInfo могут быть подписаны любым или всеми секретными ключами, соответствующими следующим сертификатам ЕЕ: секретный ключ нового сертификата подписи существующий сертификат подписи для запроса сертификата шифрования или существующий сертификат подписи для запроса обновления Эти подписи без соответствующего сертификата являются лишь проформой; они доказывают лишь то, что ЕЕ владеет секретным ключом. |
CertReqData |
{RRPID, LID-EE, Chall-EE3, [LID-CA], [Chall-CA], RequestType, RequestDate, [IDData], RegFormID, [RegForm], [CABackKeyData], publicKeySorE, [EEThumb], [Thumbs]} |
AcctInfo |
<PANData0, AcctData> Если отправитель запроса – владелец карты, вводится PANData0. Если отправитель запроса – продавец или получатель, вводится AcctData |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из RegFormRes или Me-AqCInitRes |
Chall-EE3 |
Обращение ЕЕ по поводу обновления подписи СА |
LID-CA |
Копируется из RegFormRes или из Me-AqCInitRes |
Chall-CA |
Копируется из RegFormRes или из Me-AqCInitRes |
RequestType |
Смотри таблицу 4.6.2.24 |
RequestDate |
Дата запроса сертификата |
IDData |
См. табл. 4.6.2.23. Опускается, если ЕЕ является владельцем карты. |
RegFormID |
Идентификатор, присвоенный СА |
RegForm |
{ RegFormItems +} Имена полей копируются из RegFormRes или из Me-AqCInitRes вместе со значениями, внесенными ЕЕ |
CABackKeyData |
{CAAIgId, CAKey} |
publicKeySorE |
{[ PublicKeyS], [PublicKeyE]} Общедоступный ключ объекта. Должен быть специфицирован, по крайней мере, один ключ. Пользователь может запросить сертификат подписи, сертификат шифрования или оба эти сертификата. |
EEThumb |
Оттиск сертификата ключа шифрования, который обновляется |
Thumbs |
Списки сертификатов, включая корневой, CRL и BrandCRLIdentifier, используемые в данный момент ЕЕ. |
PANData0 |
См. табл. 4.6.2.27 |
AcctData |
См. табл. 4.6.2.28 |
RegFormItems |
{FieldName, FieldValue} |
CAAlgId |
Идентификатор симметричного алгоритма шифрования |
CAKey |
Секретный ключ, соответствующий идентификатору алгоритма |
PublicKeyS |
Предлагаемый для сертификации общедоступный ключ подписи |
PublicKeyE |
Предлагаемый для сертификации общедоступный ключ шифрования |
FieldName |
Одно или более имен полей, которые надо отобразить в качестве заполняемой формы в системе отправителя запроса. Это текстовые поля с текстом на языке, специфицированном в RegFormReq или Me-AqCInitReq |
FieldValue |
Величина, введенная ЕЕ |
/p>
Таблица 4.6.2.27
. Формат PANData0
PANData0 |
{PAN, CardExpiry, CardSecret, EXNonce} |
PAN |
Первичный номер счета ( Primary Account Number) для данной карты |
CardExpiry |
Дата пригодности карты |
CardSecret |
Предложенная владельцем карты часть секретного ключа PANSecret. Эта величина используется для генерации TransStain. |
EXNonce |
Новый код (Nonce) для предотвращения атак на PANData0 |
Таблица 4.6.2.28
. Формат AcctData
AcctData |
{AcctIdentification, EXNonce} |
AcctIdentification |
Для продавца это поле уникально и определяется платежной системой карты (Brand) и получателем (банк продавца) |
EXNonce |
Новый код Nonce для предотвращения атак на PANData0 |
| Шаг | Действие |
| 1 |
Получить CertReq из входного сообщения Если RequestType соответствует новому сертификату подписи или сертификатам подписи и шифрования, то используется одна подпись CertReq. Верифицировать ее, используя новый общедоступный ключ, содержащийся в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным sigValidationFail. Если RequestType соответствует обновлению сертификата подписи или одновременному обновлению сертификатов подписи и шифрования, то используются две подписи (SignerInfos) для CertReq. Для SingerInfo с нулевым DN эмитента верифицируется подпись с использованием нового общедоступного ключа подписи, содержащегося в PublicKeyS. Если верификация не прошла, возвращается CertRes с CertStatusCode равным ValidationFail. Для SingerInfo c DN эмитента и серийным номером равными значениям из обновляемого сертификата подписи верификация подписи осущетствляется с использованием общедоступного ключа этого сертификата. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signstureFailure. Если RequestType соответствует новому или обновляемому сертификату шифрования, то для CertReq используется одна подпись. Верифицировать ее, используя общедоступный ключ сертификата подписи ЕЕ. Если верификация не прошла, возвращается сообщение Error с ErrorCode равным signatureFailure. |
| 2 | Из данных CertReqTBS запомнить RRPID, LID-EE, Chall-EE3, RequestType, LID-CA, Chall-CA, IDData, RegForm, CaBackKeyData, список оттисков и новые сертификаты подписи и/или шифрования |
| 3 | Проверить то, что RRPID и RequestDate соответствуют значениям, полученным из цифрового конверта сообщения. Если соответствия нет, выдается сообщение Error с ErrorCode равным unknownRRPID. |
| 4 | Проверить то, что полученный Chall-CA соответствует посланному в Me-AqCInitRes или RegFormRes. Если соответствия нет, выдается сообщение Error с ErrorCode равным challengeMismatch. |
| 5 | Проверить PAN (если он включен) в соответствии с политикой платежной системы (Brand), в противном случае проверить AcctData. Если соответствия нет, возвращается CertRes c кодом CertStatusCode равным rejectByIssuer. |
| 6 | Если RequestType соответствует обновлению, проверить, что сертификаты, подлежащие обновлению, не были до этого обновлены. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectedByCA. |
| 7 | Проверить то, что RegFormID корректен с точки зрения языка, RequestType и BIN или PAN. Если проверка не прошла, возвращается CertRes c кодом CertStatusCode равным rejectByCA. |
| 8 | Если отправителем CertReq является владелец карты, запомнить алгоритм и ключ, включенные в CABackKeyData, для шифрования CertRes, посылаемого владельцу карты. |
| 9 | Проверить невидимые пункты формы регистрации. Если некоторые пункты необходимы, но заполнены некорректно, вернуть CertRes с CertStatusCode равным rejectedByIssuer. |
| 10 | Если все предшествующие проверки прошли успешно, проверить все позиции регистрационной формы, проверить также, что длина, формат и типы символов правильны. Проверить, что все необходимые поля имеются. Если обнаружены какие-то ошибки, вернуть номер позиции и текст сообщений, где обнаружены ошибки в последовательности FailedItems в CertRes с CertStatusCode равным regFormAnswerMalformed. |
/p> Если верификация не прошла, СА подготавливает и отсылает сообщение CertRes c соответствующим статусом. Если обнаружены ошибки в CertReq, СА отметит эти ошибки в CertRes и приложение ЕЕ должно будет послать повторно CertReq.
При полном успехе система перейдет к аутентификации в финансовом учреждении. Здесь, прежде чем формировать сертификат, проверяется запрос CertReq. Методика этой проверки зависит от типа платежной системы (Brand) и находится за пределами спецификации SET. В зависимости от результатов проверки CertReq, CertRes будет содержать сертификат или статусный код (при неуспехе). Сообщение CertRes будет подписано и в зависимости от характера данных, уложенных в него, зашифровано. Если CertRes уведомляет владельца карты об успехе, то сообщение шифруется с использованием обычного симметричного алгоритма, поддерживаемого приложениями СА и владельца карты. Если сообщение CertRes предназначено для продавца или расчетного центра или возвращает владельцу карты статусные данные, то оно подписывается, но не шифруется.
Если CertReq аутентичен и корректен, а СА сформировал сертификат, используя представленный ключ, то будет возвращен CertRes с завершенным статусом. Если CertRes предназначен для владельца карты и содержит ключ (в CaBackKeyData) для шифрования CertRes, СA сформирует CertRes как SignedData. Осуществляется это следующим образом.
| Шаг | Действие |
| 1 |
CertResData формируется как: Копируется RRPID, LID-EE, список оттисков и Chall-EE3 из CertReq Генерируется или копируется из CertReq (если имеется) LID-CA Опционно заполняется CardLogo, URL, BrandLogo, URL, CardCurrency и/или CardholderMessage (CaMsg) CertStatusCode устанавливается равным “Request Complete” Формируется Nonce-CCA Вычисляются и заносятся оттиски EE-сертификатов, CertThumbs. Если BrandCRLIdentifier не специфицирован в списке оттисков CertReq, заполняется поле BrandCRLIdentifier. |
| 2 |
Подписать и вложить данные в цифровой конверт, используя технику EncK-инкапсуляции, для CertResData в качестве данных, подлежащих подписке. Подписать данные посредством сертификата подписи СА Установить тип данных SignedData равным id-set-content-CertResData. Вставить новые сертификаты подписи и/или шифрования ЕЕ в сертифицированной части SignedData. Зашифровать подписанные данные, используя сгенерированный вектор инициализации, а также алгоритм и ключ, представленные CABackKeyData в CertReq. Установить тип содержимого EncriptedData равным id-set-content-CertResTBE |
| 3 | Сформировать цифровой конверт и послать EE CertRes. |
/p> Если СА возвращает статус в CertRes, в него для передачи данных продавцу, владельцу карты или расчетному центру включается сообщение EEMessage. Подписанное сообщение CertRes формируется следующим образом:
| Шаг | Действие |
| 1 | Если СА сгенерировал сертификат, который будет включен в CertRes, выполняется формирование CertResTBS. |
| 2 |
Если СА не сгенерировал сертификат, т.е. имеет статус, отличный от “Request Complete”, создается CertResData: Копируется LID-EE и Chall-EE3 из CertReq Опционно заносится EEMessage Из табл. 4.6.2.30 заносится значение CertStatusCode Если CertStatusCode установлен равным regFormAnswerMalformed, занести номера позиций (ItemNumbers) и причины (ItemReasons) для каждой ошибочной позиции (FailedItem) в регистрационной форме. |
| 3 | Сформировать цифровой конверт и послать конечному пользователю (ЕЕ) CertRes |
Таблица 4.6.2.29.
Формат CertRes
CertRes |
<S(CA, CertResData), EncK(CABackKeyData, CA, CertResData)> EncK-версия этого сообщения необходима только в случае, когда в CertRes включен опционный компонент CAMsg. Эта версия используется, если в CertReq включено поле CABackKeyData |
CertResData |
{RRPID, LID-EE, Chall-EE3, LID-CA, CertStatus, [CertThumbs], [BrandCRLIdentifier], [Thumbs]} |
CABackKeyData |
Копируется из CertReq |
RRPID |
ID пары запрос/отклик |
LID-EE |
Копируется из CertReq |
Chall-EE3 |
Копируется из CertReq. Источник запроса проверяет соответствие со значением, хранящимся в памяти. |
LID-CA |
Копируется из CertReq. Если в CertReq его нет, то присваивается новое значение. |
CertStatus |
{CertStatusCode, [Nonce-CCA], EEMessage], {CaMsg], [FailedItemSeq]} |
CertThumbs |
Если запрос обслужен, то это список оттисков вложенных сертификатов подписей и/или шифрования |
BrandCRLIdentifier |
Смотри раздел об идентификаторах списков отмененных сертификатов платежной системы. |
Thumbs |
Копируется из CertReq. |
CertStatusCode |
Нумерованный код, указывающий на статус запроса сертификата |
Nonce-CCA |
Присутствует, если в качестве ЕЕ выступает владелец карты. Этот код представляет собой дополнительный секретный ключ, используемый совместно владельцем карты и ССА. |
EEMessage |
Сообщение на естественном языке, предназначенное для отображения в системе ЕЕ |
CAMsg |
{[CardLogoURL], [BrandLogoURL], [CardCurrency], [CardholderMsg]} |
FailedItemSeq |
{FailedItem+} |
CardLogoURL |
URL – указатель на логотип эмитента карты |
BrandLogoURL |
URL - указатель на логотип платежной системы |
CardCurrancy |
Вид валюта, хранящейся на счете владельца карты |
CardholderMsg |
Сообщение на естественном языке владельца карты, которое должно быть отображенопрограммой |
FailedItem |
{ItemNumber, ItemReason} |
ItemNumber |
Указывает на позицию в списке полей регистрационной формы, интерпретация которой невозможна. Значение нуль указывает на поле AcctData |
ItemReason |
Причина неудачи. Текстовое поле на естественном языке. |
/p>
Таблица 4.6.2.30
. Статусные коды для запросов сертификата
| Код | Значение | Источник |
| requestComplete | Запрос сертификата одобрен | CA |
| invalidLanguage | В запросе указан неверный язык | CA |
| invalidBIN | Запрос сертификата отклонен из-за некорректного BIN | Эмитент или получатель |
| sigValidationFail | Запрос сертификата отклонен по причине некорректной подписи | CA |
| decryptionError | Запрос сертификата отклонен из-за ошибки дешифрования | CA |
| requestInProgress | Запрос сертификата обрабатывается | СА, эмитент или получатель |
| rejectedByIssuer | Запрос сертификата отклонен эмитентом карты | Эмитент |
| requestPended | Запрос сертификата ждет обработки | СА, эмитент или получатель |
| rejectedByAquirer | Запрос сертификата отклонен банком продавца (получателем) | Получатель |
| regFormAnswerMalformed | Запрос сертификата отклонен из-за неверной позиции в регистрационной форме. | CA |
| rejectedByCA | Запрос сертификата отклонен центром сертификации | CA |
| unableToEncryptCertRes | Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты | CA |
| Шаг | Действие |
| 1 | Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier. |
| 2 | Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. |
| 3 | Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch. |
| 4 |
Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то: Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи. Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency. Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate. В случае владельца карты выполняются следующие дополнительные действия: Для того чтобы получить PANSecret, вычисляется (Nonce-CCAA CardSecret) Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата. |
| 5 | Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата. |
| 6 | Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq |
| 7 | Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage. |
/p>
Информационные сертификатные запросы и обработка статуса
Если сертификат не возвращен немедленно в CertRes, EE может попросить прислать ему информацию о состоянии его запроса путем присылки CertReq в центр СА. Запрос CertInqRes возвращает сертификат, если он готов, или предоставляет информацию о том, когда сертификат будет прислан. Такие запросы могут посылать владелец карты, продавец или расчетный центр. Адресуются эти запросы CA, CCA, MCA или PCA (источникам сертификатов).
Если CertStatusCode из CertRes равен “Certificate Request in Progress” или “Certificate Request Pending”. EE формирует CertInqReq для получения сертификата следующим образом:
| Шаг | Действие |
| 1 | Копируется LID-CA3 из CertRes в поле данных “CertInqReqTBS” |
| 2 | Генерируется новый RRPID |
| 3 | Генерируется новый LID-EE |
| 4 | Генерируется новый Chall-EE3 |
| 5 | Копируется LID-CA из предыдущего CertRes |
| 6 | Подписывается CertInqReqTBS. Устанавливается тип содержимого равным id-set-content-CertInqReqTBS. CertInqReq подписывается также как и CertReq. |
| 7 | Формируется цифровой конверт и посылается CertInqReq в центр СА. |
Таблица 4.6.2.31
. Формат CertInqReq
| CertInqReq | S(EE, CertInqReqTBS) |
| CertInqReqTBS | {RRPID, LID-EE, Chall-EE3, LID-CA} |
| RRPID | Идентификатор пары запрос/отклик |
| LID-EE | Копируется из CertRes |
| Chall-EE3 | Требование ЕЕ по поводу обновления подписи СА |
| LID-CA | Копируется из CertRes |
| Шаг | Действие |
| 1 | Из входного сообщения извлекается CertInqReq. Подпись CertInqReqTBS верифицируется также как и для CertReq. Если проверка не прошла отклик будет таким как при CertReq(EncX) |
| 2 | Проверить, что RRPID соответствует посланному в цифровом конверте. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID. |
| 3 | Используя LID-CA в качестве индекса, определяется статус CertReq. |
| 4 | Если сертификат сформирован, он посылается ЕЕ в отклике CertInqRes, в противном случае в CertInqRes возвращается актуализованный код CertStatusCode |
/p> После обработки CertInqReq СА формирует CertInqRes. Этот отклик имеет ту же структуру и формат, что и CertRes. Обработка CertInqRes происходит аналогично.
Реальный формат сертификатов определяется документом Х.509. Характеристики различных полей такого сертификата представлены в таблице 4.6.2.32.
Таблица 4.6.2.32
. Поля формата сертификата Х.509
| Имя | Ограничения на формат и значения | Описание |
| Version (Версия) | Целое | Указывает на версию сертификата |
| SerialNumber | Целое | Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат |
| Signature.AlgorithmIdentifier | OID и тип | Определяет алгоритм, используемый для генерации подписи сертификата |
| Issuer (эмитент) | Имя | Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат |
| Validity.notBefore | Время UTC | Специфицирует время, когда сертификат становится активным |
| Validity.notAfter | Время UTC | Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты. |
| Subject | Имя | Содержит уникальное имя объекта владельца ключа |
| SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier | OID и тип | Специфицирует алгоритм, который может использоваться с этим ключом. |
| SubjectPublicKeyInfo. subjectPublicKey | Строка битов | Содержит общедоступный ключ, представленный в запросе сертификата |
| IssuerUniqueID | В SET не используется | |
| SubjectUniqueID | В SET не используется | |
| Extensions.extnId | Формат OID | Содержит расширение OID, как это определено Х.509 или SET |
| Extensions.critical |
Булево: 0=ложно 1=истинно | Каждое описание расширения определяет то, какое значение должно принимать это поле |
| Extensions.extnValue | Информация расширения |
countryName [2 5 4 6]
organizationName [2 5 4 10]
organizationUnitName [2 5 4 11]
commonName [2 5 4 3]
Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType).
OID имен (ASN.1)
id-at-
countryNameOBJECT IDENTIFIER ::= { id-at 6 }
id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }
id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }
id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 }
Владелец карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName=<BrandID> (идентификатор платежной системы)
organizationalUnitName=<Название финансового учреждения, выпустившее карту>
organizationalUnitName=<Опционно - название карты>
commonName=<Уникальный идентификатор владельца карты>
Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту.
Продавец
countryName=< Страна, где размещается банк продавца – Acquirer>
organizationName=<BrandID>
organizationalUnitName=<Название банка продавца>
commonName=<Имя продавца, как написано в заявлении владельца карты>
Расчетный центр
countryName=<Страна, где размещается банк продавца – Acquirer>
organizationName=<BrandID>
organizationalUnitName=<Название банка продавца>
commonName=<Уникальный идентификатор расчетного центра>
Центр сертификации владельца карты
countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации продавца
countryName=<Страна, где размещается банк продавца – Acquirer >
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации расчетного центра
countryName=<Страна, где размещается банк продавца – Acquirer >
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Геополитический центр сертификации
countryName=<Страна геополитической организации>
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Центр сертификации платежной системы (Brand)
countryName=<Страна, где размещен центр сертификации платежной системы>
organizationName=<BrandID>
organizationalUnitName=<Описательное имя>
commonName=<Опционный уникальный идентификатор>
Корневой центр сертификации
countryName=<Страна, где размещен корневой центр сертификации – СА>
organizationName=<Корневой центр SET>
commonName=<Опционный – уникальный ID>
Поля имен в имени субъекта сертификата определены в таблице ниже:
| Country | 2 символа кода страны (ISO 3166) |
| BrandID | <Brand Name>:<Product>, где название продукта является опционным. |
| Brand Name | Платежная система карты, которая определяется разработчиками платежной системы. |
| Product Type | Опционное поле, которое определяет тип продукта в рамках заданной платежной системы. |
| Описательное имя |
Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например: Название финансовой организации Название организации, выполняющей функцию СА Название платежной системы Имя объекта, ответственного за одобрение сертификатов |
| Официальное название карты | Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д. |
| Название финансовой организации | Имя финансовой организации, выпускающей расчетные карты |
| Уникальный идентификатор владельца карты | Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета. |
| Уникальный идентификатор расчетного центра | Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN. |
/p> Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета. PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом:
Hash(KA
opad|hash((KAipad)|text)),
где A
- оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:
| K | Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA. |
| Text |
Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry. Text ::= SEQUENCE { pan PAN cardExpiry CardExpiry } PAN ::= NumberString (SIZE(1..19)) CardExpiry ::= NumericString (SIZE(6)) --YYYMM Время истечения действия карты |
| ipad | 64 байта, содержащих код 0x36 |
| opad | 64 байта, содержащих код 0x5C |
K
дополняется нулями до 64 байт.
Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName.
Профайлы сертификатов
В таблице 4.6.2.33 представлен полный список сертификатов необходимых SET.
Таблица 4.6.2.33.
Типы сертификатов
| Объект | Цифровая подпись |
Шифрование_ключей/ шифрование_данных |
Подпись keyCert |
Подпись CRL |
| Владелец карты | Х |
|||
| Продавец | Х |
Х |
||
| Расчетный центр | Х |
Х |
||
| Центр сертификации владельца карты | Х |
Х |
Х |
|
| Центр сертификации продавца | Х |
Х |
Х |
|
| Центр сертификации расчетного центра | Х |
Х |
Х |
Х |
| Геополитический центр сертификации | Х |
Х |
Х |
|
| Центр сертификации платежной системы | Х |
Х |
||
| Корневой центр сертификации | Х |
Х |
/p> ССА, MCA и PCA при совмещении функций не обязательно требуют наличия трех отдельных сертификатов. Сертификат подписи может содержать два или три различных типов сертификата.
Разные СА не обязательно требуют различных сертификатов для подписи сертификатов и CRL. Поле KeyUsage может содержать:
привилегии keyCertSign и offLineCRLSign или
keyEncipherment и dataEncipherment
В таблице 4.6.2.34 представлены обязательные расширения сертификата конечного пользователя (ЕЕ).
Таблица 4.6.2.34
. Обязательные расширения сертификата ЕЕ.
Сертификат владельца карты |
Сертификат продавца |
Сертификат расчетного центра |
|||
| Расширение Х.509 | Подпись |
Подпись |
Шифрова-ние ключа |
Подпись |
Шифрова-ние ключа |
| AuthorityKeyIdentifier | Х |
Х |
Х |
Х |
Х |
| KeyUsage | Х |
Х |
Х |
Х |
Х |
| PrivateKeyUsagePeriod | Х |
Х |
Х |
||
| CertificatePolicies | Х |
Х |
Х |
Х |
Х |
| SubjectAltName | O |
O |
O |
O |
O |
| BasicConstraints | Х |
Х |
Х |
Х |
Х |
| IssuerAltName | O |
O |
O |
O |
O |
| Частное расширение | |||||
| HashedRootKey | |||||
| CertificateType | Х |
Х |
Х |
Х |
Х |
| MerchantData | Х |
Х |
|||
| CardCertRequired | Х |
||||
| Tunneling |
Х |
||||
| SETExtensions | Х |
Х – обязательный
O - опционный
Таблица 4.6.2.35
. Обязательные расширения сертификатов СА
| СА | Корневой центр сертификации | ||||
| Расширение Х.509 |
Цифровая подпись |
Подпись серти-фиката |
Шифрова-ние ключа |
Подпись CRL |
Подпись сертификата & CRL |
| AuthorityKeyIdentifier | Х |
Х |
Х |
Х |
Х |
| KeyUsage | Х |
Х |
Х |
Х |
Х |
| PrivateKeyUsagePeriod | Х |
Х |
Х |
||
| CertificatePolicies | Х |
Х |
Х |
Х |
Х |
| SubjectAltName | O |
O |
O |
O |
O |
| BasicConstraints | Х |
Х |
Х |
Х |
Х |
| IssuerAltName | O |
O |
O |
O |
O |
| Частное расширение | |||||
| HashedRootKey | Х |
||||
| CertificateType | Х |
Х |
Х |
Х |
Х |
| MerchantData | |||||
| CardCertRequired | |||||
| Tunneling | Х |
||||
| SETExtensions |
/p> Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:
Номер CRL. Номера монотонно возрастают.
Список серийных номеров устаревших сертификатов.
Даты, когда конкретные сертификаты были признаны устаревшими.
Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).
Уникальное имя СА, который поддерживает данный CRL.
Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL.
В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509).
Таблица 4.6.2.36
. Формат полей CRL и ограничения для их значений
| Имя поля | Формат и ограничения на значение | Описание |
| CRL.version (версия) | Целое; V2 | Определяет версию CRL. В настоящее время =2. |
|
CRL.signature .algorithmIdentifier |
OID и тип | Определяет алгоритм, использованный для подписи CRL |
| CRL.Issuer | Имя | Содержит DN субъекта для СА, который выпустил устаревший сертификат. Должен совпадать с именем субъекта в сертификате СА |
| CRL.thisUpdate | Время UTC | Определяет время, когда был сформирован CRL |
| CRL.nextUpdate | Время UTC | Определяет время, когда CRL устареет |
|
CRL.revokedCertificate .certSerialNumber |
Целое | Номер по порядку устаревшего сертификата |
|
CRL. RevokedCertificate .revocationDate |
Время UTC | Дата признания сертификата устаревшим |
|
CRL. RevokedCertificate .extensions |
Расширения | Не используется в SET |
| CRL.extensions | Расширения | В этом поле используются два расширения: CRLNumber и AuthorityKeyIdentifier |
/p> Следующие СA должны поддерживать CRL в рамках SET:
корневой СА – для поддержки незапланированной замены корневых сертификатов или сертификатов СА платежных систем.
СА платежных систем – для поддержки незапланированной замены или прекращения действия сертификата, выданного центром сертификации платежной системы.
геополитические СА – для поддержки незапланированной замены сертификатов CCA, MCA или PCA.
CA расчетного центра - для поддержки незапланированной замены сертификатов ключевого обмена расчетного центра.
Расширение CRLNumber содержит одно целое число. Центр СА, подписывающий CRL, должен инкрементировать это число каждый раз при выпуске нового CRL.
При получении нового CRL должны проводиться следующие проверки:
1. Сначала проверяется подпись:
Используется AuthorityKeyIdentifier расширения CRL для контроля корректности сертификата подписи.
Расширение KeyUsage в сертификате подписи указывает на CRLsign(6)
2. IssuerDN рассматриваемого сертификата должен соответствовать полю IssuerDN в CRL.
3. IssuerDN и устаревший certSerialNumber сравниваются с проверяемым сертификатом
Следующие проверки производятся для того, чтобы выяснить, не входит ли данный сертификат в список CRL:
IssuerDN рассматриваемого сертификата должен соответствовать содержимому поля IssuerDN CRL
certSerialNumber должно соответствовать значению поля revokedCertificates.certSerialNumber списка CRL.
Существующие CRL от одного и того же IssuerDN могут быть удалены, когда успешно прошел проверку CRL с более высоким значением CRLNumber.
BrandCRLIdentifier
BrandCRLIdentifier (BCI) представляет собой структуру, определенную SET и используемую для идентификации всех рабочих CRL заданной области ответственности сертификационного центра платежной системы. BrandCRLIdentifier содержит в себе следующую информацию:
Номер BCI (увеличивается для каждого нового BCI)
Название платежной системы
Время пригодности BCI
Список номеров CRL (из расширения номера CRL)
Эмитент и серийный номер сертификата СА платежной системы, который используется для подписи BCI (включается в расширение)
Подпись BCI производится с привлечением секретного ключа, соответствующего сертификату CRLSign. BCI пересылаются владельцам карт и продавцам в виде сообщений-откликов.
Запросы и отклики сертификатов
Запрос сертификата посылается клиентом вышестоящему центру сертификации (СА). Последний формирует сертификат и отсылает его отправителю запроса в подписанном сообщении отклике. Различные объекты ответственны за подпись разных сертификатов, как это показано ниже.
| Сертификат для: | Формируется и подписывается: |
| СА платежной системы | Корневой СА |
| Геополитический СА | СА платежной системы |
| ССА, МСА или РСА | Геополитический СА, если таковой имеется, в противном случае СА платежной системы |
Сообщение-запрос сертификата включает в себя информацию, которая должна присутствовать в расширениях сертификата. Эта информация содержится в атрибутах запроса PKCS#10. В таблице 4.6.2.37 показаны атрибуты, которые необходимы или опционны в CertificationRequest.
Таблица 4.6.2.37
. Атрибуты CertificationRequest
| ССА, МСА или РСА | Геополитический центр сертификации или СА платежной системы | ||||
| Атрибут SET | Сертификат подписи | Подпись CRL | Сертификат и подпись CRL | ||
| KeyUsage | X |
X |
X |
X |
X |
| PrivateKeyUsagePeriod | X |
X |
X |
X |
|
| AdditionalPolicy | O |
O |
O |
O |
O |
| SubjectAltName | O |
O |
O |
O |
O |
| CertificateType | X |
X |
X |
X |
X |
| Tunneling | X |
Х –
обязательный
O - опционный
При получении CertificationRequest СА должен проверить запрос и сформировать отклик в соответствии со следующей процедурой:
| Шаг | Действие |
| 1 | Используя процедуру, определенную платежной системой, проверить аутентичность CertificationRequest |
| 2 | Используя общедоступный ключ, присланный в запросе, проверить подпись |
| 3 | Проверить, что уникальное имя субъекта (Distinguished Name) согласуется с форматом Certificate Subject Name |
| 4 | Используя тип сертификата и атрибуты использования ключа, проверить, что имеются необходимые атрибуты (см. таблицу 4.6.2.37) |
| 5 | Для сертификатов подписи проверить, что запрошенный PrivateKeyUsagePeriod находится в пределах допустимого диапазона пригодности по времени для подписывающего СА, и что дата notBefore в запрошенном PrivateKeyUsagePeriod находится в пределах допустимого для подписывающего СА. |
| 6 | Если какая-либо из вышеперечисленных проверок не прошла, сертификат не будет сформирован. |
| 7 | Если верификация прошла успешно, сертификат формируется с применением атрибутов, включенных в запрос. Сформированный сертификат помещается в соответствующую секцию SignedData. |
| 8 | SignedData помещается в цифровой конверт и посылается отправителю запроса. Транспортные механизмы находятся вне зоны ответственности SET. |
/p>
Рассылка CRL
CRL представляет собой механизм, определенный Х.509, и предназначенный для публикации и рассылки списков выведенных из употребления сертификатов, срок действия которых еще не истек. Когда корневой СА актуализует свой CRL, он посылает его каждому центру сертификации платежной системы. Когда нижерасположенный центр сертификации актуализует свой CRL, он рассылает его своим СА платежных систем. CRL рассылаются в секции SignedData сообщений CRLNotification согласно следующему алгоритму.
| Шаг | Действие |
| 1 |
Сформировать CRLNotificationTBS: Занести в поле данные текущую дату Занести в CRLThumbprint оттиск, несущий в себе CRL |
| 2 | Подписать содержимое, используя сертификат подписи СА. Установить тип содержимого равным id-set-content-CRLNotificationTBS |
| 3 | Внести новый CRL в CRL-секцию SignedData. Вложить CRL в сертификационную секцию сообщения. |
| 4 | Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotification. Следует заметить, что это не SET-сообщение. SignedData подвергается DER-кодированию и вкладывается в цифровой конверт MIME. |
| Название поля | Описание |
| CRL-Notification | S(CA, CRLNotificationTBS) |
| CRL-NotificationTBS | {Date, CRLThumbprint} |
| Дата | Дата, когда сформировано сообщение |
| CRLThumbprint | Оттиск CRL, заключенный в CRL-секцию SignedData |
| Шаг | Действие |
| 1 | Если дата раньше, чем для любого предыдущего CRL, полученного от этого СА, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом ошибки badDate. |
| 2 | Если CRL-оттиск не согласуется с тем, который записан в CRL-секции SignedData, сообщение проигнорировать и откликнуться отправившему СА сообщением Error c кодом thumbMismatch. |
| 3 | Запомнить модифицированный CRL и послать СА платежной системы для добавления в последующее сообщение рассылки BCI. |
| Шаг | Действие |
| 1 |
Заполнить NotificationResTBS: Вставить дату из сообщения CRLNotification Вставить оттиск полученного CRL |
| 2 |
Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-CRLNotificationResTBS |
| 3 | Закодировать и вложить в цифровой конверт подписанное сообщение CRLNotificationRes в форме согласованной с транспортным механизмом. Послать сообщение отклика CRLNotification запросившему СА. |
/p> Сообщение-отклик CRLNotification содержит следующие поля.
| Название поля | Описание |
| CRL-NotificationRes | S(CA, CRLNotificationTBS) |
| CRL-NotificationResTBS | {Date, CRLThumbprint} |
| Дата | Копируется из сообщения CRLNotification |
| CRLThumbprint | Оттиск CRL, копируется из сообщения CRLNotification |
Получение BCI
BrandCRLIdentifier (BCI) является списком текущих CRL, соответствующим всем СА из зоны ответственности платежной системы (Brand). Центр сертификации платежной системы отвечает за поддержку, корректность и актуальность BCI. Каждый CA из зоны ответственности платежной системы отвечает за обновление и осуществление доступа к BCI и соответствующим спискам CRL. Эту информацию они выдают в виде откликов на запросы ЕЕ или нижестоящих СА.
Центр сертификации каждой платежной системы формирует и поддерживает свой BCI и реализует механизм для рассылки этой информации. СА, например, расчетного центра должен организовать ежедневное обновление этих данных.
Центр сертификации платежной системы рассылает информацию о новых CRL в виде сообщений BCI Distribution. Это сообщение является подписанным, содержащим текущую дату, BCI, соответствующие сертификаты и CRL. Сообщение BCI Distribution
не формируется ежедневно, а лишь по мере необходимости. Алгоритм формирования этого сообщения представлен ниже.
| Шаг | Действие |
| 1 |
Заполнить BCIDistributionTBS: Ввести текущую дату Включить последнюю версию BCI |
| 2 | Подписать содержимое, используя сертификат подписи центра сертификации платежной системы. Установить contenttype равным id-set-content-BCIDistributionTBS. В CRL секцию SignedData ввести все CRL, перечисленные в BCI. В сертификатную часть вставить все сертификаты, необходимые для верификации всех CRL. |
| 3 | Закодировать и вложить в цифровой конверт подписанное сообщение BCIDistribution в форме, согласованной с транспортным механизмом. |
/p> Сообщение BCI Distribution содержит в себе следующие поля:
| Название поля | Описание |
BCIDistribution |
S(CA, BCIDistributionTBS) |
BCIDistributionResTBS |
{Date, BCIDistribution} |
Дата |
Дата формирования сообщения |
BrandCRLIdentifier |
Список текущих CRL для всех СА в зоне ответственности центра сертификации платежной системы и корневого СА. Сообщение подписывается сертификационным центром платежной системы. |
| Шаг | Действие |
| 1 | Извлечь BCIDistribution из транспортного сообщения. Проверить подпись сообщения, используя сертификат подписи СА платежной системы. |
| 2 | Если дата относится к моменту времени раньше, чем та, что в предыдущем сообщении BCIDistribution, сообщение следует выбросить. |
| 3 | Если BrandCRLIdentifier отличается от текущего, проверить подпись каждого CRL из BCI. Если подпись некорректна или список CRL из перечня BCI не включен в сообщение, оно отбрасывается. |
| 4 | Запомнить все CRL и BrandCRLIdentifier для последующей рассылки |
Структуры данных
Сообщения SET включают в себя несколько структур данных, которые содержат информационные элементы, переносимые из одного сообщения в другое. Информационные поля сообщения с протокольной точки зрения непрозрачны.
TransID
TransID предоставляет всю информацию для уникально определенной транзакции и характеристики транзакции, частью которой является данное сообщение. В частности TransID позволяет участнику процесса связать каждое сообщение с определенной транзакцией. Структура данных в TransID представлена ниже в таблице.
TransID |
{LID-C, [LID-M], XID, PReqData, [PaySysID], Language} |
LID-C |
Локальный ID. Метка, генерируемая системой владельца карты или для нее. |
LID-M |
Локальный ID. Метка, генерируемая системой продавца или для нее. |
XID |
Глобально уникальный идентификатор |
PReqData |
Дата запроса покупки. Генерируется продавцом в PInitRes или владельцем карты в PReq. |
PaySysID |
Используется некоторыми платежными системами для пометки транзакций |
Language |
Естественный язык владельца карты |
/p> TransID предоставляет несколько идентификаторов для транзакций. LID-C, LID-M и PaySysID являются идентификаторами, которые присваиваются владельцем карты, продавцом и/или платежной системой. LID-M часто используется для хранения номера заказа продавца для данной транзакции. PreqData предоставляет дату запуска транзакции. XID представляет собой идентификатор транзакции, который обычно формируется системой продавца, если только нет PInitRes, в последнем случае он формируется системой владельца карты. XID представляет собой псевдослучайный 20 байтовый код, который должен быть уникальным. В таблице 4.6.2.38 рассмотрено, когда формируется и используется поле TransID в сообщениях SET.
Таблица 4.6.2.38
. Условия формирования и использование поля TransID
| Сообщение | LID-C | LID-M | XID | PaySysID |
| PInitReq | R | C1 | N/P | N/P |
| PInitRes |
? |
? (C2) |
R | N/P |
| PReq |
? |
? |
? (R3) |
N/P |
| PRes |
? |
? (C2) |
? |
C4 |
| InqReq |
? |
? |
? |
C5 |
| InqRes |
? |
? |
? |
C4 |
| AuthReq |
? |
? |
? |
N/P |
| AuthRes |
? |
? |
? |
C6 |
| AuthRevReq |
? |
? |
? |
C |
| AuthRevRes |
? |
? |
? |
? |
| CapReq | I | I | I | I |
| CapRes | I | I | I | I |
| CapRevReq | I | I | I | I |
| CapRevRes | I | I | I | I |
| CredReq | I | I | I | I |
| CredRes | I | I | I | I |
| CredRevReq | I | I | I | I |
| CredRevRes | I | I | I | I |
| PCertReq | N/P | C | N/P | N/P |
| PCertRes | N/P |
? |
N/P | N/P |
| BatchAdminReq | I | I | I | I |
| BatchAdminRes | I | I | I | I |
| CardCInitReq | R | N/P | N/P | N/P |
| CardCInitRes |
? |
N/P | N/P | N/P |
| Me-AdCInitReq | N/P | C | N/P | N/P |
| Me-AdCInitRes | N/P |
? |
N/P | N/P |
| RegFormReq |
? |
? |
N/P | N/P |
| RegFormRes |
? |
? |
N/P | N/P |
| CertReq |
? |
? |
N/P | N/P |
| CertRes |
? |
? |
N/P | N/P |
| CertInqReq |
? |
? |
N/P | N/P |
| CertInqRes |
? |
? |
N/P | N/P |
| R | Поле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт. |
| C | Наличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения. |
| N/P | (Not Present) Отсутствует как в сообщении так и в цифровом конверте. |
|
? |
Копируется из запроса или предыдущего сообщения, дублируется в цифровом конверте |
| I | Может присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте. |
/p> Примечания:
Копируется из процесса инициализации SET (если имеется)
Если для данной транзакции нет предшествующего LID-M, продавец может сформировать его для данного сообщения.
Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.
Если послано после получения AuthRes с PaySysID
Если послано после получения PRes с PaySysID
Может быть сформировано расчетным центром для данного сообщения.
Алгоритм формирования TransID представлен ниже:
| Шаг | Действие |
| 1 | Если сообщение для данной транзакции получено раньше, следует запомнить все его поля. |
| 2 | Если это новая транзакция, сформировать все необходимые поля (см таблицу выше) |
| 3 | Заполнить любые опционные поля, которые могут быть сформированы данным объектом. |
Платежная инструкция
Платежная инструкция (PI) является одной из важнейших информационных структур SET. Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца – Acquirer). Эта информация не может быть прочитана продавцом.
Имеется три разновидности PI. Первые два формируются владельцем карты, третье – расчетным центром.
PIUnsigned |
Формируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned. Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится. |
PIDualSigned |
Формируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных. |
AuthToken |
Формируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq. Этот вариант используется для поддержки доставки по частям и передается назад из расчетного центра после первичной авторизации с тем, чтобы использоваться для запросов последующих авторизаций. |
/p> Платежная инструкция имеет структуру представленную в таблице 4.6.2.39.
Таблица 4.6.2.39
. Структура PI
PI |
<PIUnsigned, PIDualSigned, AuthToken> Владелец карты создает PIUnsigned или PIDualSigned инструкцию. Расчетный центр формирует AuthToken для поддержки поставки по частям и последовательных платежей. Продавец запишет PI для последующего вложения в AuthReq. |
PIUnsigned |
EXH(P, PI-OILink, PANToken )} (См. табл. 4.6.2.46) |
PIDualSigned |
{PISignature, EX(P, PI-OILink, PANData)} (См. табл. 4.6.2.45) |
AuthToken |
См. табл. 4.6.2.42 |
PI-OILink |
L(PIHead, OIData) (см. табл. 4.6.2.40) |
PISignature |
SO(C, PI-TBS) |
PI-TBS |
{HPIData, HOIData} |
HPIData |
DD(PIData) |
HOIData |
DD(OIData) |
PIData |
{PIHead, PANData} (см. табл. 4.6.2.40 и 4.6.2.45) |
Таблица 4.6.2.40
. Структура PIHead
PIHead |
{TransIDs, Inputs, MerchantID, [InstallRecurData], TransStain, SWIdent, [AcqBackKeyData], [PIExtensions]} |
TransIDs |
См. выше описание TransIDs |
Inputs |
{HOD, PurchAmt} |
MerchantID |
Копируется из сертификата подписи продавца |
InstallRecurData |
См. табл. 4.6.2.41 |
TransStain |
HMAC(XID, CardSecret) |
SWIdent |
Строка, идентифицирующая программное обеспечение (разработчик и версия), инициирующее запрос. Оно специфицируется в PI, чтобы расчетный центр знал программное обеспечение владельца карты. |
AcqBackKeyData |
{AcqBackAlg, AcqBackKey} |
PIExtensions |
Данные из расширения платежных инструкций должны быть финансовыми и важными для обработки авторизации расчетного центра, эмитента или финансовой сети |
Таблица 4.6.2.41
. Структура InstallRecurData
InstallRecurData |
{InstallRecurDInd, [IRExtensions]} |
InstallRecurDInd |
< InstallTotalTrans, Recurring > |
IRExtensions |
Данные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра |
InstallTotalTrans |
Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей |
Recurring |
{RecurringFrequency, RecurringExpiry} |
RecurringFrequency |
Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями) |
RecurringExpiry |
Окончательная дата, после которой никакие авторизации не разрешены |
/p> Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту.
AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42.
Таблица 4.6.2.42
. Структура AuthToken
AuthTokenData |
{TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque} |
PANToken |
Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40) |
TransIDs |
|
PurchAmt |
|
MerchantID |
|
AcqBackKeyData |
|
InstallRecurData |
|
RecurringCount |
Число реализованных рекуррентных авторизаций |
PrevAuthDateTime |
Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций |
TotalAuthAmount |
Полное число авторизованных в результате всех авторизаций для данного XID |
AuthTokenOpaque |
Невидимые данные, генерируемые расчетным центром |
| Шаг | Действие |
| 1 |
Генерируется AuthTokenTBE как: Если это первая авторизация (выполнена согласно PI) а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData б. RecurringCount делается равным 1 в. В PrevAuthDateTime записывается текущая дата г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthToken Если это очередная аутентификация (сгенерирована из предыдущего AuthToken) а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData б. Инкрементируется на 1 RecurringCount в. В PrevAuthDateTime записывается текущая дата г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthToken Если это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken) а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1 в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken. |
| 2 | Сформировать PANToken (см. табл. 4.6.2.46) |
| 3 | С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p. |
/p> Обработка AuthToken выполняется в следующем порядке:
| Шаг | Действие |
| 1 | Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра. |
| 2 | Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed |
| 3 | Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch. |
| 4 |
Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией: Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon. |
| 5 | Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты. |
| 6 | Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу. |
Таблица 4.6.2.43
. Структура AcqCardMsg
AcqCardMsg |
EncK(AcqBackKeyData, P, AcqCardCodeMsg) AcqBackKeyData предоставляется владельцем карты в PI. Зашифрованное сообщение адресуется владельцу карты. |
AcqBackKeyData |
Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40) |
AcqCardCodeMsg |
{AcqCardCode, AcqCardMsgData} |
AcqCardCode |
Числовой код |
AcqCardMsgData |
{[AcqCardText], [AcqCardURL], [AcqCardPhone]} |
AcqCardText |
Текстовое сообщение, отображаемое владельцу карты |
AcqCardURL |
URL HTML-сообщения, отображаемого владельцу карты |
AcqCardPhone |
Телефонный номер, предоставляемый владельцу карты |
/p> Для AcqCardCode определены следующие значения:
| messageOfDay | Банк продавца хочет, чтобы это сообщение было передано всем |
| accountInfo | Информация о счете должна быть передана назад пользователю |
| сallCustomerService | Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов |
CapToken
предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44.
Таблица 4.6.2.44
. Структура CapToken
CapToken |
<Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}> P1 и P2 обозначают платежные центры: P1 – отправителя P2 - получателя В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2) |
CapTokenData |
{AuthRRPID, AuthAmt, TokenOpaque} |
PANToken |
Смотри табл. 4.6.2.46 |
AuthRRPID |
RRPID, который появляется в соответствующем AuthReq или AuthRevReq |
AuthAmt |
Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты |
TokenOpaque |
Невидимые данные, определенные расчетным центром |
| Шаг | Действие |
| 1 | Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes |
| 2 | Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов |
| 3 |
Если продавец получает PANToken из своего банка, тогда: Занести PANToken из PI Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секции В противном случае: Использовать Enc инкапсуляцию с CapTokenData |
| Шаг | Действие |
| 1 | Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc. |
| 2 | Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest. |
| 3 | Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound |
| 4 | Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest. |
| 5 | Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса. |
/p> PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45.
Таблица 4.6.2.45.
Структура PANData
PANData |
{PAN, CardExpiry, PANSecret, EXNonce} |
PAN |
Первичный номер счета, обычно номер счета карты |
CardExpiry |
Дата действительности карты |
PANSecrit |
Секретный код, используемый совместно владельцем карты, расчетным центром и сертификационным центром владельца карты. Предотвращает атаки на PAN в сертификате владельца карты. |
EXNonce |
Новый код (Nonce), который препятствует атаке на PANData |
| Шаг | Действие |
| 1 | Занести в PAN номер счета владельца карты |
| 2 | Записать в CardExpiry дату действительности карты |
| 3 | Занести PANSecret, который был получен от СА вместе с сертификатом владельца карты. Для владельца карты без сертификата все октеты этого поля устанавливаются равными нулю. |
| 4 | Сформировать новое значение EXNonce |
Таблица 4.6.2.46.
Структура PANToken
PANToken |
{PAN, CardExpiry, EXNonce} |
PAN |
Первичный номер счета, обычно номер счета карты |
CardExpiry |
Дата действительности карты |
EXNonce |
Новый код (Nonce), который препятствует атаке на PANData |
| Шаг | Действие |
| 1 | Занести в PAN номер счета владельца карты |
| 2 | Записать в CardExpiry дату действительности карты |
| 3 | Сформировать новое значение EXNonce. |
Структура SaleDetail
SaleDetail соединяет в себе данные, относящиеся к текущей транзакции. Эта структура формируется как часть установления процесса между продавцом и расчетным центром. Для AuthReq, CredReq и CapReq формирование продавцом SaleDetail является опционным. Структура данных в SaleDetail показана в таблице 4.6.2.47.
Таблица 4.6.2.47. Структура SaleDetail
SaleDetail |
{[BatchID],[BatchSequenceNum], [PayRecurInd], [MerOrderNum], [AuthCharInd], [MarketSpecSaleData], [CommercialCardData], [OrderSummery], [CustomerReferenceNumber], [CustomerServicePhone], OktoPrintPhoneInd, [SaleExtensions]} Это поле может появляться в AuthReq с флагом CaptureNow установленным равным TRUE или в сообщениях, связанных с платежным запросом. |
BatchID |
Идентификация последовательности операций в системе продавец и его банк |
BatchSequenceNum |
Порядковый номер позиции в данной последовательности расчетных операций. |
PayRecurInd |
Номер типа транзакции |
MerOrderNum |
Номер заказа продавца |
AuthCharInd |
Копируется из AuthResPayload |
MarketSpecSaleData |
{[MarketSpecDataID], [MarketSpecCapData]} |
CommercialCardData |
Описание позиции в платежном запросе (см. табл. 4.6.2.48) |
OrderSummary |
Краткое описание заказа |
CustomerReferenceNumber |
Номер ссылки, присвоенный заказу владельца карты |
CustomerServicePhone |
Номер телефона службы обслуживания клиентов данного продавца |
OKtoPrintPhoneInd |
Булево число, указывающее, может ли эмитент выдавать телефон службы сервиса в ответ на запрос владельца карты. |
SaleExtensions |
Данные этого расширения должны быть финансовыми и важными для обработки платежного запроса расчетного центра или эмитента |
MarketSpecDataID |
Копируется из AuthResPayload |
MarketSpecCapData |
<MarketAutoCap, MarketHotelCap, MarketTransportCap> |
MarketAutoCap |
Описание оплаты проката автомобиля (см. табл. 4.6.2.49) |
MarketHotelCap |
Описание оплаты гостиницы (см. табл. 4.6.2.50) |
MarketTransportCap |
Данные о пассажире (см. табл. 4.6.2.51) |
| unknown | Тип транзакции неизвестен |
| singleTransaction | Транзакция состоит из одной авторизации и платежного запроса |
| recurringTransaction | Транзакция состоит из нескольких авторизаций и платежных запросов, которые повторяются регулярно |
| installmentPayment | Транзакция состоит из нескольких авторизаций и заказов-резервирований, которые выполняются фиксированное число раз |
| otherMailOrder | Прочие транзакции заказов по почте |
/p> Структура коммерческих данных карты представлена в таблице 4.6.2.48.
Таблица 4.6.2.48
. Структура коммерческих данных карты
CommercialCardData |
{[ChargeInfo], [MerchantLocation], [ShipFrom], [ShipTo], [ItemSeq]} |
ChargeInfo |
{[TotalFreightShippingAmount], [TotalDutyTariffAmount], [DutyTariffReference], [TotalNationalTaxAmount], [TotalLocalTaxAmount], [TotalOtherTaxAmount], [TotalTaxAmount], [MerchantTaxID], [MerchantDutyTariffRef], [CustomerDutyTariffRef], [SummaryCommodityCode], [MerchantType]} |
MerchantLocation |
Местоположение продавца |
ShipFrom |
Адрес отправки |
ShipTo |
Адрес получателя |
ItemSeq |
{Item +} Номера от 1 до 999 |
TotalFreightShippingAmount |
Общее количество позиций, подлежащих обработке и доставке |
TotalDutyTariffAmount |
Полная сумма налога или тариф для заказа |
DutyTariffReference |
Код ссылки, приписанный налогу или тарифу для данного заказа |
TotalNationalTaxAmount |
Полная величина национального налога (с продаж или на добавленную стоимость), распространяющегося на данный заказ |
TotalLocalTaxAmount |
Размер местного налога, распространяющегося на данный заказ |
TotalOtherTaxAmount |
Прочие налоги, действующие для данного заказа |
TotalTaxAmount |
Полный размер налога для данного заказа |
MerchantTaxID |
Индивидуальный идентификационный номер продавца |
MerchantDutyTariffRef |
Код налога или тарифа, приписанный продавцу |
CustomerDutyTariffRef |
Код налога или тарифа, приписанный владельцу карты |
SummaryCommodityCode |
Код товара, приложимый ко всему заказу |
MerchantType |
Тип продавца |
Item |
{Quantity, [UnitOfMeasureCode], Descriptor, [CommodityCode], [ProductCode], [UnitCost], [NetCost], DiscountInd, [DiscountInd], [NationalTaxAmount], [NationalTaxAmount], [NationalTaxRate], [NationalTaxType], [LocalTaxAmount], [LocalTaxAmount], ItemTotalCost} |
Quantity |
Количество предметов или услуг данного типа |
UnitOfMeasureCode |
Единицы измерения для данной позиции в заказе |
Descriptor |
Описание позиции в заказе |
CommodityCode |
Код вида товара для данной позиции заказа |
ProductCode |
Код продукта для данной позиции заказа |
UnitCost |
Цена единицы товара |
NetCost |
Чистая цена единицы товара |
DiscountInd |
Указывает, распространяется ли скидка на данную позицию в заказе |
DiscountAmount |
Величина скидки для данной позиции заказа |
NationalTaxAmount |
Величина национального налога, применимого к данной позиции заказа |
NationalTaxRate |
Национальный налог (с продаж или на добавленную стоимость), применимый к данной позиции заказа |
NationalTaxType |
Ставка национального налога, действующая для данной позиции заказа |
LocalTaxAmount |
Величина местного налога, действующая для данной позиции заказа |
OtherTaxAmount |
Величина прочих налогов |
ItemTotalCost |
Полная цена данной строки заказа |
/p> Структура данных MarketAutoCap представлена в таблице 4.6.2.49.
Таблица 4.6.2.49
. Структура MarketAutoCap
MarketAutoCap |
{[RenterName], [RentalLocation], RentalDateTime, [AutoNoShow], [RentalAgreementNumber], [ReferenceNumber], [InsuranceType], [InsuranceType], [ReturnLocation], ReturnDateTime, AutoCharges} |
RenterName |
Имя лица, сдающего авто в аренду |
RentalLocation |
Адрес фирмы сдающей авто в аренду |
RentalDateTime |
Дата (опционно время), когда авто было взято в аренду |
AutoNoShow |
Числовой код, указывающий, что клиент не предъявил во время арендованную машину |
RentalAgreementNumber |
Номер арендного соглашения |
ReferenceNumber |
Код аренды |
InsuranceType |
Тип страховки, выбранный арендатором |
AutoRateInfo |
{AutoApplicableRate, [LateReturnHourlyRate], [LateReturnHourlyRate], [FreeDistance], [VehicleClassCode], [CirporateID]} |
ReturnLocation |
Адрес фирмы, куда следует вернуть авто (см. табл. 4.6.2.51) |
ReturnDateTime |
Дата (опционно время) возвращения автомобиля |
AutoCharges |
{RegularDistanceCharges, [LateReturnCharges], [TotalDistance], [ExtraDistanceCharges], [InsuranceCharges], [FuelCharges], [AutoTowingCharges], [OneWayDropOffCharges], [TelephoneCharges], [ViolationsCharges], [DelivaryCharges], [ParkingCharges], [OtherCharges], [TotalTaxAmount], [AuditAdjustment]} |
AutoApplicableRate |
<DailyRentalRate, WeeklyRentalRate> |
LateReturnHourlyRate |
Почасовая плата за опоздание возврата |
DistanceRate |
Помильная оплата за превышение допустимого пробега |
FreeDistance |
Расстояние, которое может пройти машина в день, без увеличения арендной платы. |
VehicleClassCode |
Класс арендуемого автомобиля |
CorporateID |
Корпоративный идентификационный номер, который применяется для определения арендной платы |
RegularDistanceCharges |
Сумма расходов за аренду (исключая расходы, перечисленные ниже) |
LateReturnCharges |
Сумма выплаты за возвращения автомобиля после оговоренного срока. |
TotalDistance |
Полный пробег автомобиля. |
ExtraDistanceCharges |
Сумма оплаты избыточного пробега (сверх оговоренного в договоре) |
InsuranceCharges |
Сумма страховки |
FuelCharges |
Оплата горючего |
AutoTowingCharges |
Оплата буксировки |
OneWayDropOffCharges |
Оплата одностороннего разрыва арендного договора |
TelephoneCharges |
Расходы использования телефона в арендованной машине |
ViolationsCharges |
Сумма штрафов за нарушения за время аренды автомобиля |
DelivaryCharges |
Оплата доставки арендованного автомобиля |
ParkingCharges |
Оплата парковки арендованного автомобиля |
OtherCharges |
Оплата расходов, не определенных в других позициях |
TotalTaxAmount |
Сумма налогов, связанная с арендой автомобиля |
AuditAdjustment |
Сумма изменения объема транзакции в результате аудита в компании, предоставляющей автомобили в аренду. |
DailyRentalRate |
Дневная арендная плата |
WeeklyRentalRate |
Арендная плата за неделю |
/p> Структура данных MarketHotelCap представлена в таблице 4.6.2.50.
Таблица 4.6.2.50
. Структура MarketHotelCap
MarketHotelCap |
{[ArriveDate], [RentalLocation], DepartureDate, [DurationOfStay], [FolioNumber], [PropertyPhone], [CustomerServicePhone], [ProgramCode], [HotelRateInfo], HotelCharges} |
ArriveDate |
Дата регистрации владельца карты в отеле |
HotelNoShow |
Цифровой код, указывающий, что клиент не был зарегистрирован в этом отеле своевременно |
DepartureDate |
Дата отбытия владельца карты из отеля |
DurationOfStay |
Число дней пребывания владельца карты в отеле |
FolioNumber |
Номер книги |
PropertyPhone |
Номер телефона отеля |
CustomerServicePhone |
Номер телефона системы обслуживания клиентов отеля или сети отелей |
ProgramCode |
Код, указывающий тип специальной программы пребывания клиента |
HotelRateInfo |
{DailyRoomRate, [DailyTaxRate]} |
HotelCharges |
{RoomCharges, [RoomTax], [PrepaidExpenses], [FoodBeverageCharges], [RoomServiceCharges], [MiniBarCharges], [LaundryCharges], [TelephoneCharges], [BusinessCenterCharges], [ParkingCharges], [MovieCharges], [HealthClubCharges], [GiftShopCharges], [FolioCashAdvances], [OtherCharges], [TotalTaxAmount ], [AuditAdjustment]} |
DailyRoomRate |
Стоимость проживания в день. В эту сумму входят налоги, если не специфицирована переменная DailyTaxRate. |
DailyTaxRate |
Размер налога за проживание одного дня в гостинице |
RoomCharges |
Полная стоимость проживания в номере с учетом дополнительных расходов, перечисленных ниже |
RoomTax |
Налог, взымаемый с суммы RoomCharges |
PrepaidExpenses |
Полный размер предоплаты |
FoodBeverageCharges |
Оплата еды и напитков |
RoomServiceCharges |
Оплата обслуживания номера |
MiniBarCharges |
Оплата пользования минибаром |
LaundryCharges |
Оплата услуг прачечной |
TelephoneCharges |
Плата за пользование телефоном |
BusinessCenterCharges |
Оплата за услуги бизнес-центра |
ParkingCharges |
Оплата парковки |
MovieCharges |
Оплата за просмотр фильмов в номере |
HealthClubCharges |
Оплата услуг оздоровительного клуба |
GiftShopCharges |
Оплата покупок в сувенирном магазине |
FolioCashAdvances |
Сумма, предварительно внесенная за номер |
OtherCharges |
Другие расходы |
TotalTaxAmount |
Сумма налогов, включенная в счет |
AuditAdjustment |
Изменение платежа в результате перепроверки расчетов в отеле |
/p> Структура данных MarketTransportCap представлена в таблице 4.6.2.51.
Таблица 4.6.2.51
. Структура MarketTransportCap
MarketTransportCap |
{PassangerName, DepartureDate, OrigCityAirport, [TripLegSeq], [TicketNumber], [TravelAgencyCode], [TravelAgencyName], [Restrictions]} |
PassangerName |
Имя пассажира, кому выдается билет |
DepartureDate |
Дата отбытия |
OrigCityAirport |
Город начала путешествия |
TripLegSeq |
{TripLeg +} от одной до 10 TripLeg-записей |
TicketNumber |
Номер билета |
TravelAgencyCode |
Код турагенства |
TravelAgencyName |
Название турагенства |
Restrictions |
Численный код, указывающий на ограничения выплат и расходов |
TripLeg |
{DateOfTravel, CarrierCode, ServiceClass, StopOverCode, DestCityAirport, [FareBasisCode], [DepartureTax]} |
DateOfTravel |
Дата путешествия |
CarrierCode |
Код перевозчика данного тура |
ServiceClass |
Класс услуг тура |
StopOverCode |
Числовой код, указывающий на допустимость остановок в пути при совершении тура |
DestCityAirport |
Аэропорт места назначения тура |
FareBasisCode |
Код базовой цены тура |
DepartureTax |
Налог при отбытии для данного тура |
Location |
{CountryCode, [City], [StateProvince], [PostalCode], [LocationID]} |
CountryCode |
Код страны ISO 3166 |
City |
Название города |
StateProvince |
Название или аббревиатура штата или провинции |
PostalCode |
Почтовый код |
LocationID |
Идентификатор, который использует продавец, чтобы специфицировать один из своих адресов |
Таблица 4.6.2.52
. Структура RRTags
RRTags |
{ RRPID, MerTermIDs, Date} |
RRPID |
Новый идентификатор пары запрос/отклик |
MerTermIDs |
{MerTermIDs, [TerminalID], [AgentNum], [ChainNum], [StoreNum]} |
Date |
Текущая дата для устаревающих записей |
MerchantID |
Владелец карты заносит эти данные в PIHead. Этот код копируется из MerID в сертификат подписи продавца. |
TerminalID |
Продавец вводит эти данные в AuthReq. |
AgentNum |
Продавец вводит эти данные в AuthReq. |
ChainNum |
Продавец вводит эти данные в AuthReq. |
StoreNum |
Продавец вводит эти данные в AuthReq. |
/p> Формирование RRTags производится следующим образом
| Шаг | Действие |
| 1 | Формируется новый RRPID и запоминается в базе данных транзакции. |
| 2 | Заносятся MerTermIDs из записанных данных продавца, описывающих место продажи. |
| 3 | Записывается текущая дата в поле Date. |
Таблица 4.6.2.53
. Структура BatchStatus
BatchStatus |
{OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]} |
OpenDateTime |
Дата и время открытия платежной линии |
ClosedWhen |
{CloseStatus, CloseDateTime} |
BatchDetails |
{CloseDateTime, [BrandBatchDetailsSeq]} |
BatchExtensions |
Данные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса |
CloseStatus |
Цифровой код, указывающий статус закрытия платежной линии |
CloseDateTime |
Дата и время закрытия платежной линии |
BatchTotals |
{TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]} |
BrandBatchDetailsSeq |
{BrandBatchDetails +} |
TransactionCountCredit |
Число транзакций, которые внесли вклад в кредит продавца. |
TransactionTotalAmtCredit |
Полная сумма, внесенная на счет продавца |
TransactionCountDebit |
Число транзакций, которые внесли вклад в дебет продавца |
TransactionTotalAmtDebit |
Полная сумма, снятая со счета продавца |
BatchTotalExtensions |
Данные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail. |
BrandBatchDetails |
{BrandID, BatchTotals} |
BrandID |
Тип платежной системы карты без типа продукта |
/p> Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54.
Таблица 4.6.2.54
. Структура TransactionDetail
TransactionDetail |
{TransIDs, AuthRRPID, BrandID, BatchSequenceNum, [ReimbursementID], TransactionAmt, TransactionAmtType, [TransactionStatus], [TransExtensions]} |
TransIDs |
Идентификаторы транзакций обработки авторизации/оплаты для заданной позиции |
AuthRRPID |
RRPID, который присутствует в соответствующих AuthReq или AuthRevReq |
BrandID |
Платежная система карты (без типа продукта) |
BatchSequenceNum |
Порядковый номер позиции в пакете платежей |
ReimbursmentID |
Цифровой код, указывающий на тип оплаты для заданной позиции |
TransactionAmt |
Сумма для позиции, тип которой указан в TransactionAmtType. Сумма всегда обозначается положительным числом. |
TransactionAmtType |
Цифровой код, указывающий тип суммы (кредит или дебет) |
TransactionStatus |
Цифровой код, индицирующий результат прохождения транзакции для вышестоящей системы |
TransExtensions |
Данные в расширении для административного отклика последовательности платежей (batch) должны иметь финансовый характер и использоваться при обработке административного запроса для заданной последовательности платежей. Информация, имеющая отношение к обработке запроса должна размещаться в расширении BatchAdminResData. |
| Поле | Определение |
| currency (валюта) | Значение представляется в виде строки ASCII-символов, характеризующей три цифры кода валюты (ISO 4217) Например, платеж в долларах США будет обозначен кодом 840. Возможные значения лежат в диапазоне 1-999 включительно. |
| amount (cумма) | Значение представляется в виде строки ASCII-символов, характеризующей сумму платежа в указанной валюте. Значение должно соответствовать положительному числу. |
| amtExp10 |
Значение представляется в виде строки ASCII-символов, характеризующей десятичный показатель степени: cумма * (10amtExp10). Значение может быть как положительным, так и отрицательным. |
/p> Для того чтобы представить сумму US $2.87 в поле PurchAmt, в поля currency, amount и amtExp10 заносятся коды 840, 250 и –2.
Поля Date
Даты в SET обычно указываются в форме строк, характеризующих календарную дату и время UTC в формате:
YYYYMMDDHHMM[SS[.f]f]f]]]Z
где Z литерал буквы Z в верхнем регистре. Таким образом, строка должна состоять из четырех цифр, характеризующих год, по две цифры, определяющие месяц, день, час (24-часовое представление) и минуту. После минут опционно могут присутствовать две цифры секунд. Если поле секунд присутствует, далее могут опционно быть прописаны доли секунды. Запись может иметь, например, форму:
20011003102853.33Z,
что означает 2001 год, 03 октября, 10 часов 28 минут 53,33 секунды. Полночь отмечается датой, следующего дня.
Поток платежных сообщений
Основу потока платежных сообщений SET составляют пары запрос/отклик, следующие между владельцем карты и продавцом, а также между продавцом и расчетным центром. Основу обмена между владельцем карты и продавцом составляют сообщения PReq/PRes. Сообщение PRes может быть прислано немедленно или спустя некоторое время. Присылаемая информация зависит от фазы реализации протокола, в которой находится система.
Авторизация продавца в расчетном центре выполняется с помощью сообщений AuthReq/AuthRes.
На рис. 4.6.2.14 показан типичный пример обмена сообщениями при реализации протокола покупки.
Рис. 4.6.2.14. Диаграмма обмена для протокола покупки
На рис. 4.6.2.15 показаны все возможные сообщения, которые могут иметь место при обработке транзакции (опционные сообщения отмечены курсивом). Следует заметить, что приведенный порядок обмена является рекомендуемым, и допускается его изменение.
Рис. 4.6.2.15. Опции обмена сообщениями при покупке
Рис. 4.6.2.15а. (продолжение)
Пары сообщений InqReq/InqRes позволяют владельцу карты получать информацию о состоянии транзакции. Запрос InqReq может быть послан в любое время после посылке продавцу PReq. В паре сообщений PReq/PRes владелец карты уведомляет продавца о том, что же он хочет купить. Сообщения AuthRevReq и AuthRevRes используются тогда, когда необходимо возобновить авторизацию. Сообщения CapRevReq и CAPRevRes организуют процесс отмены оплаты покупки, прежде чем сделка будет завершена. Пара CredReq и CredRes сходна с предыдущей парой, но используется после завершения сделки. Сообщения PCertReq/PCertRes обеспечивают для продавца механизм получения сертификата шифрования, который необходим для шифрования сообщения расчетному центру. BatchAdminReq и BatchAdminRes служат продавцу для открытия, закрытия и выяснения статуса транзакции его платежной линии с расчетным центром. Сообщения Error служат для уведомления об ошибках в протоколе или при обработке.
Обработка запросов/откликов инициализации платежа
Процедура инициализации платежа включает в себя обмен двумя сообщениями. Первоначальный запрос PInitReq посылает владелец карты, отклик PInitRes ему присылает продавец. Задачей этого обмена является получение владельцем карты сертификатов и CRL. Без такого обмена данная информация может быть получена и каким-то другим образом, например с CD-ROM. Эти сообщения посылаются после инициализации процесса SET. Сообщение-запрос PInitReq идентифицирует платежную систему карты (Brand), предоставляет локальный идентификатор владельца карты для данной транзакции, посылает переменную вызова для определения пригодности (свежести) сообщения-отклика. В этом сообщении передается также набор оттисков, который идентифицирует соответствующие сертификаты и CRL, уже имеющиеся у владельца карты, чтобы их не нужно было посылать еще раз.
Сообщение-отклик PInitRes содержит запрошенные данные, включая сертификаты и CRL. Присылается продавцом также дата, XID и вызов владельца карты, добавляется, кроме того, и вызов продавца. Алгоритм формирования владельцем карты сообщения PInitReq приведен в таблице ниже.
| Шаг | Действие |
| 1 | Сформировать RRPID для идентификации сообщения и установления соответствия между запросом и откликом |
| 2 | Занести в поле Language, значение которое выбрал владелец карты для данной транзакции |
| 3 | Сформировать идентификатор LID-C, который является идентификатором пары сообщений, так как XID еще не присвоен. Этому полю могут присваиваться числа натурального ряда или случайные коды. |
| 4 | Если продавец при инициации SET-процесса предоставил код LID-M, скопировать его в сообщение. |
| 5 | Сформировать новый код Chall-C |
| 6 | На основе выбранной формы платежа заполнить BrandID (из программы-магазина или из программы инициализации SET). |
| 7 | Заполнить поле BIN (первые 6 цифр номера счета владельца карты) |
| 8 | Опционно. Заполнить оттиски для сертификатов, CRL и BrandCRLIdentifier, имеющиеся у владельца карты. Сюда должен входить корневой сертификат. |
| 9 | Записать в базу данных транзакций RRPID, LID-C, LID-M (если имеется), Chall-C и оттиски (если имеются). |
| 10 | Опционно. Заполнить любые расширения PInitReq. |
| 11 | Занести все это в цифровой конверт и послать продавцу |
/p> Сообщение PInitReq, задавая естественный язык владельца карты, определяет ID и контекст транзакции, а также спецификацию платежной системы. Кроме того, предоставляются оттиски, где записаны сертификаты и криптографические вызовы, гарантирующие новизну отклика. Структура PInitReq представлена в таблице 4.6.2.55.
Таблица 4.6.2.55
. Структура PInitReq
PInitReq |
{ RRPID, Language, LID-C, [LID-M], Chall-C, BrandID, BIN, [Thumbs], [PIRqExtensions]} |
RRPID |
Идентификатор пары запрос/отклик |
Language |
Естественный язык владельца карты |
LID-C |
Локальный ID. Метка, формируемая системой владельца карты или для нее. |
LID-M |
Копируется из сообщения инициации SET (если имеется) |
Chall-C |
Вызов владельца карты, служащий для гарантии новизны подписи продавца |
BrandID |
Выбранная владельцем карты платежная система |
BIN |
Номер идентификации банка из номера счета владельца карты (первые 6 цифр) |
Thumbs |
Оттиски списка сертификатов, CRL и BrandCRLIdentifier из кэша владельца карты |
PIRqExtensions |
Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных. |
| Шаг | Действие |
| 1 | Извлечь запрос из входного сообщения |
| 2 |
Если LID-M присутствует, найти запись транзакции, базирующуюся на LID-M. Если запись не найдена: Прислать сообщение Error c ErrorCode равным unknownLID Прервать обработку PInitReq |
| 3 | Если LID-M отсутствует, найти запись транзакции, на основе критериев, выходящим за пределы регламентаций SET. Если продавец не сформировал LID-M для этой транзакции, опционно сгенерировать LID-M и занести его в запись транзакции. |
| 4 | Сформировать новый XID |
| 5 | Занести XID, RRPID, Language, LID-C, Chall-C, BrandID и BIN в запись транзакции |
| 6 | Если оттиски присутствуют, произвести спасение записи транзакции |
| 7 | Если имеется какое-либо расширение PInitReq, произвести его обработку. Если расширение не распознано и флаг критичности равен TRUE, сформировать сообщение Error, в противном случае игнорировать расширение. Если расширение распознано, его следует обработать. |
/p> Формирование продавцом отклика PInitRes осуществляется следующим образом.
| Шаг | Действие |
| 1 |
Сформировать структуру данных PInitRes следующим образом: Сгенерировать TransID согласно следующей процедуре: Скопировать LID-C, XID и Language из записи транзакции Если запись транзакции содержит LID-M, скопировать его Занести текущую дату в TransIDs.PReqDate Скопировать RRPID из записи транзакции Скопировать Chall-C из записи транзакции Сформировать новый Chall-M Если оттиск для текущего BrandCRLIdentifier не получен или устарел, занести новый BrandCRLIdentifier На основе информации из PInitReq (BrandID, BIN и сертификат владельца карты) выбрать расчетный центр. Записать в PEThumb оттиск сертификата выбранного расчетного центра. Скопировать оттиски из PInitReq, если он имеется. Это позволяет владельцу карты проверить, что продавцу корректно доставлены все посланные оттиски. Опционно: добавить любые PIRqExtensions |
| 2 | Ввести Compose SignedData. Если оттиск для Cert-PE не получен в PInitReq, включить в подпись Cert-PE. |
| 3 | Вставить все эти данные в цифровой конверт и послать владельцу карты |
Таблица 4.6.2.56
. Структура PInitRes
PInitRes |
S(M, PInitResData) |
PInitResData |
{TransIDs, RRPID, Chall-C, Chall-M, [BrandCRLIdentifier], PEThumb, [Thumbs], [PIRsExtensions]} |
TransIDs |
Смотри описание структуры TransID выше |
RRPID |
Идентификатор пары запрос/отклик |
Chall-C |
Копируется из сообщения PInitReq |
Chall-M |
Вызов продавца, служащий для проверки новизны подписи владельца карты |
BrandCRLIdentifier |
Список текущих CRL для всех СА в рамках заданной платежной системы. |
PEThumb |
Оттиск сертификата ключевого обмена расчетного центра. |
Thumbs |
Копируется из PInitReq |
PIRsExtensions |
Запрос инициализации покупки незашифрован, по этой причине эти расширения не должны содержать конфиденциальных данных. |
| Шаг | Действие |
| 1 | Извлечь PInitRes из входного сообщения |
| 2 | Вызвать Receive SignedData |
| 3 |
Проверить TransID следующим образом: Осуществить поиск транзакции с использованием LID-C. Если поиск безуспешен: Послать сообщения Error с ErrorCode равным unknownLID Остановить обработку PInitRes Если LID-M был послан во время инициализационного процесса SET, сравнить LID-M с LID-M в записи транзакции. Если они неэквивалентны, то: Послать сообщение Error с ErrorCode равным unknownLID Остановить обработку PInitRes с) Если LID-M не был послан и имеется LID-M, то: Послать сообщение Error с ErrorCode равным unknownLID Остановить обработку PInitRes |
| 4 |
Сравнить RRPID со значением из записи транзакции. Если они отличаются, то: Послать сообщение Error с ErrorCode равным unknownRRPID Остановить обработку PInitRes |
| 5 |
Сравнить Сhall-C со значением из записи транзакции. Если они отличаются, то: Послать сообщение Error с ErrorCode равным challengeMismatch. Остановить обработку PInitRes |
| 6 | В опционном варианте управления со стороны владельца карты из сертификата продавца извлекается его имя и отображается для пользователя. Если владелец карты одобряет кандидатуру, процесс продолжается, в противном случае обработка PInitRes прерывается. |
| 7 | Занести данные, включая TransID и Chall-M, в запись транзакции |
| 8 | Обработать BrandCRLIdentifier, если он присутствует. |
| 9 | Использовать PEThumb для идентификации сертификата шифрования (Cert-PE), чтобы использовать в PReq при шифровании данных для расчетного центра. |
| 10 | Проверить, что сертификат платежной системы продавца и сертификат расчетного центра (Cert-PE) согласуются с платежной системой владельца карты, указанной в PInitReq. Если согласия нет, владелец карты оповещается об этом, а обработка PInitReq прерывается. |
| 11 |
Если поле Thumbs присутствует, сравнить его значение с тем, что прислано в PInitReq. Если значения совпадают, перейти к исполнению пункта 14, в противном случае: Послать сообщение Error с ErrorCode равным thumbsMismatch Остановить обработку PInitRes |
| 12 |
Если поле Thumbs отсутствует, проверить, что Thumbs не было послано в PInitReq. Если Thumbs было послано в PInitReq, то: Послать сообщение Error с ErrorCode равным thumbsMismatch Остановить обработку PInitRes |
| 13 | Если PIRsExtensions существуют, их необходимо обработать. Если они не распознаны, а флаг критичности (criticality) равен TRUE, сформировать сообщение Error, в противном случае расширения следует игнорировать. |
| 14 | Проверить Cert-PE (идентифицированный в PEThumb) для неподписанных транзакций. Если индикатор в Cert-PE не допускает неподписанных транзакций, а владелец карты не имеет сертификата, информировать его о том, что транзакция не может быть продолжена и прервать обработку. |
| 15 | Владелец карты может теперь продолжить процедуру посылкой запроса покупки. |
/p> Запросы инициализации покупки (PInitReq) несут в себе достаточно информации о владельце карты для программы продавца, чтобы выбрать сертификат платежного центра. Следует иметь в виду, что эти запросы не шифруются и соответствующие расширения не должны нести в себе конфиденциальной информации.
Отклик на запрос инициализации (PInitRes) содержит копии данных из запроса PInitReq, а также сертификаты продавца и расчетного центра. Отклик подписывается продавцом, что позволяет владельцу карты быть уверенным в том, что посланная им в запросе информация дошла до продавца неискаженной (за счет просмотра копий). Отклик PInitRes также не шифруется.
Обработка заказа-покупки
Обмен запрос-отклик (PReq/PRes) представляет собой реализацию покупки, выполняемой владельцем карты у продавца. Данные сообщения составляют ядро протокола купли-продажи. На долю владельца карты выпадает функция платежа.
Реализация запроса покупки проходит через 5 этапов (см. рис. 4.6.2.16).
Рис. 4.6.2.16. Обработка запроса покупки
Прежде чем послать запрос покупки покупатель (владелец карты) должен заполнить форму заказа, одобрить условия сделки и выбрать платежную карту. Для того чтобы послать запрос продавцу, владелец карты должен иметь копию ключей расчетного центра. Обработка заказа начинается, когда программа владельца карты запрашивает копию сертификата расчетного центра. В этом сообщении содержится информация о выборе платежной системы. Когда продавец получает запрос, он присваивает транзакции уникальный идентификатор. После этого продавец пересылает свой сертификат и сертификат расчетного центра вместе с этим идентификатором владельцу карты. Программа владельца карты верифицирует полученные сертификаты и запоминает их для использования в последующей обработке заказов. Приложение владельца карты формирует данные заказа OI (Order Information) и платежные инструкции PI. OI и PI снабжаются идентификатором транзакции, для того чтобы расчетный центр мог связать их вместе при авторизации запроса продавца. Заметим, что OI не содержит таких данных как описание товара или условий поставки. Эта информация получается на фазе сделки, предшествующей операциям SET (например, в рамках протокола IOTP).
Программное обеспечение владельца карты генерирует двойную цифровую подпись для OI и PI путем вычисления дайджеста для обоих модулей данных, объединения этих дайджестов, вычисления дайджеста результата и осуществления подписи этого сообщения с привлечением секретного ключа владельца карты. Дайджесты OI и PI посылаются вместе с этим сообщением. Далее программа формирует симметричный ключ и использует его для шифрования дважды подписанных PI. Затем программа шифрует номер счета владельца карты и симметричный ключ с привлечением общедоступного ключа расчетного центра. Результат составляет цифровой конверт сообщения, которое передается продавцу.
Когда программа продавца получает заказ, она верифицирует сертификат подписи владельца карты, используя общедоступный ключ владельца карты и дайджест PI (заключенный в OI), проверяет цифровую подпись, чтобы убедиться в не искаженности заказа и в том, что сообщение подписано секретным ключом владельца карты. Заметим, что продавцу не обязательно выполнять авторизацию до посылки отклика владельцу карты. Последний может позднее определить, была ли выполнена авторизация, послав информационный статусный запрос. После обработки OI продавец генерирует отклик и снабжает его цифровой подписью. Этот отклик содержит в себе сертификат подписи продавца и указывает на факт получения заказа от владельца карты. Если отклик авторизации указывает на одобрение транзакции, продавец поставляет товар или услугу, указанные в заказе.
Когда приложение владельца карты получает отклик на запрос покупки от продавца, сначала верифицируется сертификат подписи. Далее проверяется цифровая подпись продавца. При благоприятном исходе этих проверок выдается соответствующее сообщение и производится запись в базу данных. Состояние выполнения заказа владелец карты может выяснить путем посылки информационных статусных запросов.
Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись.
PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:
C PI используется OAEP
В блок OAEP включается H(PIHead) (вместе с PANData)
С PIHead используется H(OIData)
Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead.
Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).
| Шаг | Действие | |
| 1 | Извлечь PurchAmt и OD | |
| 2 | Сформировать OIData следующим образом: | |
| a) | Если имел место обмен PInitReq/ PInitRes: | Скопировать TransIDs из PInitRes |
| В противном случае: | Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID | |
| b) | Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца | |
| Если имел место обмен PInitReq/PInitRes: | Скопировать Chall-c из PInitRes | |
| В противном случае: | Сформировать новый Chall-C | |
| c) | Сформировать новый ODSalt | |
| d) |
Сформировать HODInput посредством следующей процедуры: Скопировать OD из данных процесса инициализации SET Записать PurchAmt cо значением, одобренным владельцем карты на фазе инициации SET. Скопировать ODSalt из пункта 2 с) Если владелец карты намерен выполнить инсталляцию или последовательные платежи, то записать InstallRecurData Опционно: добавить любые ODExtensions | |
| e) | Сформировать HOD с HODInput из пункта 2 d | |
| f) | Если имел место обмен PInitReq/ PInitRes: | Скопировать Chall-M из PInitRes и не заполнять BrandID |
| В противном случае: |
Не заполнять Chall-M Записать BrandID, указав предпочтительный тип карты | |
| g) | Произвести записьв поле BIN с HODInput из пункта 2d | |
| h) | Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш | |
| i) | Опционно: добавить любые расширения OIExtensions. | |
| 3 | Сформировать PIHead следующим образом: | |
| a) | Скопировать TransIDs, вычисленные в пункте 2.а | |
| b) |
Сгенерировать Inputs согласно процедуре: Скопировать HOD из пункта 2.е Скопировать PurchAmt из шага 2.d.2 | |
| c) | Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога | |
| d) | Скопировать InstallRecurData из пункта 2.d.4 (если имеется) | |
| e) | Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями. | |
| f) | Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения | |
| g) |
Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом: Найти туннельное расширение для алгоритма шифрования, приемлемое для владельца карты. Если такое найдено, заполнить AcqBackAlg, в противном случае, не формировать AcqBackInfo и перейти к пункту f. Сформировать новый AcqBackKey (приемлемый для AcqBackAlg) | |
| h) | Опционно добавить любые PIExtensions | |
| 4 | Сформировать PANData | |
| 5 | Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2) | |
| 6 | Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет. |
/p> Когда расчетный центр готов шифровать данные для конечного пользователя (ЕЕ), его сертификат содержит список симметричных алгоритмов шифрования, которые он поддерживает, в порядке их предпочтения. Конечный пользователь, который хочет иметь шифрованные данные, выбирает первый алгоритм из списка, который он способен использовать. Ключ для этого алгоритма передается расчетному центру в сообщении PReq.
Реализация PReqDualSigned рассмотрена ниже.
| Шаг | Действие |
| 1 |
Сформировать PISignature: Сформировать PI-TBS: Сгенерировать HPIData в виде дайджеста PIData Сгенерировать HOIData в виде дайджеста OIData Выполнить PISinature c оператором S0, используя сертификат владельца карты (параметр s) и PI-TBS (параметр t). |
| 2 | Применить оператор EX, используя общедоступный ключ расчетного центра (параметр r), PI-OILink от владельца карты создает PReq шаг 5 (параметр t), а PANData от владельца карты создает PReq шаг 4 (параметр p) |
| 3 | Образовать PIDualSigned как объединение подписи PISignature, вычисленной в пункте 1, и шифрованных данных, полученных на шаге 2. |
| 4 | Генерируем PIData как объединение HIHead из PReq владельца карты, (см. пункт 3 предшествующей таблицы), и PANData владельца карты, которая создается в пункте 4 при формировании PReq (см. предшеств. табл.). |
| 5 | Генерируем OIDualSigned, посредством оператора L, используя OIData от владельца карты, создаем PReq - пункт 2 (параметр t1) и данные PIData, полученные в пункте 4 (параметр t2) |
| 6 | Генерируем PReqDualSigned как объединение PIDualSigned из пункта 3 и OIDualSigned из пункта 5. |
Таблица 4.6.2.57.
Структура PReqDualSigned
| PReqDualSigned | {PIDualSigned, OIDualSigned} |
| PIDualSigned | Смотри описание PI (выше) |
| OIDualSigned | L(OIDualSigned, PIData) |
| OIData | Смотри табл. 4.6.2.59 |
| PIData | {PIHead, PANData} |
Таблица 4.6.2.58
. Структура PReqUnsigned
| PReqUnsigned | {PIUnsigned, OIUnsigned} |
| PIUnsigned | Смотри описание PI (выше) |
| OIUnsigned | L(OIData, PIDataUnsigned) |
| OIData | Смотри табл. 4.6.2.59 |
| PIDataUnsigned | {PIHead, PANToken} (см. табл. 4.6.2.40 и 4.6.2.45) |
Таблица 4.6.2.59
. Структура PReq для PReqDualSigned и PreqUnsigned
| OIData | {TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]} |
| TransIDs | Копируется из PInitRes, если имеется |
| RRPID | ID пары запрос/отклик |
| Chall-C | Копируется из соответствующего PInitReq (см. табл. 4.6.2.55) |
| HOD |
DD(HODInput) Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью |
| ODSalt | Копируется из HODInput |
| Chall-M | Вызов продавца владельцу карты относительно свежести подписи |
| BrandID | Выбранная владельцем карты платежная система |
| BIN | Идентификационный номер банка из номера счета владельца карты (первые 6 цифр) |
| ODExtOIDs | Список объектных идентификаторов из ODExtensions |
| OIExtensions | Данные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации. |
| HODInput | {OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]} |
| OD | Описание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д. |
| PurchAmt | Число транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40). |
| ODSalt | Новое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD. |
| InstallRecurData | См. табл. 4.6.2.41 |
| ODExtensions | Данные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу. |
/p> При получении PReq продавец производит следующие действия.
| Шаг | Действие |
| 1 | Извлекает PReq из входного сообщения |
| 2 |
Если получено PReqDualSigned, производит проверку подписи; Извлекает OIData и HPData из OIDualsigned Формирует HOIData в виде дайджеста OIData Формирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В. Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t). Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq. Переходит к выполнению пункта 4. |
| 3 |
Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то: Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись) Останавливает обработку PReq |
| 4 |
Производит обработку TransIDs: Проводит поиск транзакций, базирующихся на XID. Если запись такой транзакции найдена Сравнивает LID-C и LID-M с записью. Если соответствия нет: Возвращает сообщение Error c ErrorCode = unknownLID Останавливает обработку PReq В противном случае сверяет Chall-M с записью. Если соответствия нет, то: Присылает сообщение Error c ErrorCode = challengeMismatch Останавливает обработку PReq В противном случае Формирует новую запись транзакции Спасает LID-C, PReqDate и Language Опционно формирует LID-M |
| 5 |
Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то: Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен) Останавливает обработку PReq |
| 6 | Запоминает Chall-C, чтобы вернуть его в последующем PRes |
| 7 | Запоминает оставшиеся переменные из сообщения в базе данных |
| 8 | Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется) |
| 9 | Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes |
/p> После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:
| Шаг | Действие |
| 1 |
Сформировать PResData: Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центра Скопировать RRPID из PReq (или из InqReq) Скопировать Chall-C из PReq (или из InqReq) Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifier Сформировать PresPayloadSeq: Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2. Если расчетный центр отклонил заказ, сформировать PresPayload: Установить CompletionCode = orderReject Скопировать AcqCardMsg из AuthRes, если имеется. Перейти к пункту 2 Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2. Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2. Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже |
| 2 | Ввести Compose SignedData |
| 3 | Вставить сообщение в цифровой конверт и послать владельцу карты |
| Шаг | Действие |
| 1 |
Если выполнена только авторизация: Установить CompletionCode = authorizationPerformed Сформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq. |
| 2 |
Если оплата (capture) выполнена: Установить CompletionCode = capturePerformed Сформировать Results, как это описано ниже, опуская CredStatusSeq |
| 3 |
Если кредитование осуществлено; Установить CompletionCode = creditPerformed Сформировать Results, как это описано ниже |
| 4 | Опционно добавить любые PRsExtensions |
/p> Формирование поля Results производится согласно следующему алгоритму:
| Шаг | Действие |
| 1 | Скопировать AcqCardMsg из AuthRes, если этот отклик имеется |
| 2 |
Если позиция авторизована, сформировать AuthStatus: Скопировать AuthDate из записи транзакции Скопировать AuthCode из записи транзакции Вычислить AuthRatio, как AuthReqAmt ? PurchAmt Если в AuthRes присутствуют данные о конвертации валюты, скопировать их |
| 3 |
Если позиция оплачена, сформировать CapStatus: Скопировать CapDate из записи транзакции Скопировать CapCode из записи транзакции Вычислить CapRatio, как CapReqAmt ? PurchAmt |
| 4 |
Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus: Скопировать CreditDate из записи транзакции Скопировать CreditCode из записи транзакции Вычислить CreditRatio, как CapRevOrCredReqAmt ? PurchAmt |
Таблица 4.6.2.60
. Структура PRes, формируемая продавцом
PRes |
S(M, PresData) |
PResData |
{TransIDs, RRPID, Chall-C, [BrandCRLIdentifier], PresPayloadSeq} |
TransIDs |
Копируется из PReq |
RRPID |
Идентификатор пары запрос/отклик |
Chall-C |
Копируется из соответствующего PInitReq |
BrandCRLIdentifier |
Список текущих CRL для всех СА в зоне ответственности СА платежной системы |
PResPayloadSeq |
{PresPayload +} Одна запись для каждой выполненной авторизации. Отмена авторизации удаляет запись из PResPayload. Если не было авторизаций, появляется одна позиция с соответствующей статусной записью |
PResPayload |
См. табл. 4.6.2.61 |
Таблица 4.6.2.61
. Структура PResPayload
PResPayload |
{CompletionCode, [Results], [PrsExtensions]} |
CompletionCode |
Цифровой код, указывающий на состояние завершения транзакции |
Results |
{[AcqCardMsg], [AuthStatus], [AuthStatus], [CredStatusSeq]} |
PRsExtensions |
Отклик на запрос покупки не зашифрован и по этой причине не должен содержать конфиденциальную информацию |
AcqCardMsg |
Копируется из AuthRes (см. табл. 4.6.2.43) |
AuthStatus |
{AuthDate, AuthCode, AuthRatio, [CurrConv]} |
CapStatus |
{CapData, CapCode, CapRatio} Данные присутствуют здесь, только если CapReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные. |
CredStatusSeq |
{CredStatus +} Данные присутствуют, только если CredReq соответствует выполненной авторизации. Сообщение CredRevReq удаляет эти данные. |
AuthDate |
Данные авторизации. Копируются из AuthRRTags.Date (см. табл. 4.6.2.64) |
AuthCode |
Цифровой код, указывающий на состояние авторизационного процесса. Копируется из AuthResPayload. |
AuthRatio |
AuthReqAmt ? PurchAmt |
CurrConv |
{CurrConvRate, CardCurr} Информация о конвертировании валюты, копируется из AuthResPayload |
CapData |
Дата оплаты, копируется из CapPayload |
CapCode |
Цифровой код, указывающий на состояние оплаты, копируется из CapResPayload |
CapRatio |
CapReqAmt ? PurchAmt |
CreditStatus |
{CreditDate, CreditCode, CreditRatio} Данные присутствуют, только если реализован запрос CreditReq. Эта информация удаляется CredRevReq |
CreditDate |
Дата кредита. Копируется из CapRevOrCredCode. |
CreditCode |
Цифровой код, указывающий на состояние кредита. Копируется из CapRevOrCredResPayload.CapRevOrCredCode. (см. табл. 4.6.2.74) |
CreditRatio |
CapRevOrCredReqAmt ? PurchAmt |
/p> Коды завершения (completionCode) могут принимать следующие значения (см. табл. 4.6.2.62).
Таблица 4.6.2.62
. Коды завершения операции
meanonglessRatio |
PurchAmt=0; отношение не может быть вычислено |
orderRejected |
Продавец не может обработать заказ |
orderReceived |
Процессы авторизации отсутствуют |
orderNotReceived |
Информационный запрос получен до заказа |
authorizationPerformed |
См. AuthStatus |
capturePerformed |
См. CapStatus |
creditPerformed |
См. CreditStatus |
| Шаг | Действие |
| 1 | Извлекается отклик из входного сообщения |
| 2 | Чтобы проверить подпись продавца, производится обращение к Received Signed Data, |
| 3 |
На основе Trans.LID-C ищется запись транзакции. Если запись не найдена: Посылается сообщение Error c ErrorCode равным unknownLID Прерывается обработка PRes |
| 4 |
Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет: Посылается сообщение Error c ErrorCode равным unknownXID Прерывается обработка PRes |
| 5 |
Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным unknownRRPID Прерывается обработка PRes |
| 6 |
Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным challengeMismatch Прерывается обработка PRes |
| 7 | Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной. |
| 8 |
Для каждого PResPayload из PresPayloadSeq выполняются следующие действия: Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmount*AuthRatio). В противном случае сообщить результат транзакции на основе CompletionCode. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы. |
/p>
Обработка информационных запросов
Пара сообщений InqReq/ InqRes позволяет владельцу карты получать информацию о состоянии транзакции. Информационный запрос может быть послан в любое время после запроса PReq, адресованного продавцу. Запросы InqReq могут посылаться многократно. Отклик InqRes имеет тот же формат, что и PRes. Продавец должен проверять, что сертификат, сопровождающий InqRes, соответствует сертификату, использованному с PRes. Это препятствует запросам одного владельца карты о состоянии транзакций других покупок. Владелец карты без сертификатов не подписывает информационные запросы, что означает возможность нарушения целостности сообщения. Владелец карты формирует запрос InqReq следующим образом.
| Шаг | Действие |
| 1 |
Копируется InqReqData из предыдущего запроса Формируется новый RRPID Генерируется новый Chall-С Опционно добавляются любые InqReqExtensions |
| 2 | Если владелец карты послал подписанный PReq, вставить Compose SignedData c InqReqData |
| 3 | Вставить сообщение в цифровой конверт и послать продавцу |
Таблица 4.6.2.63.
Структура InqReq
InqReq |
<InqReqSigned, InqReqData> |
InqReqSigned |
S(C, InqReqData) |
InqReqData |
{TransIDs, RRPID, Chall-C2, [InqRqExtensions]} |
TransIDs |
Копируется из самого последнего: PReq, PRes, InqReq |
RRPID |
Идентификатор пары запрос/отклик |
Chall-C2 |
Новый вызов владельца карты по поводу подписи продавца. |
InqRqExtensions |
Информационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации. |
| Шаг | Действие |
| 1 | Извлекается запрос из входного сообщения |
| 2 |
Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда: Прислать сообщение InqRes c CompletionCode = signatureRequired. Прервать обработку InqReq В противном случае перейти к пункту 4. |
| 3 |
Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла: Прислать сообщение Error с ErrorCode = signatureFailure Прервать обработку InqReq |
| 4 |
Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет: Прислать сообщение Error c ErrorCode = wrapperMsgMismatch Прервать обработку InqReq |
| 5 |
Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен: Прислать InqRes c CompletionCode = orderNotReceived. Прервать обработку InqReq |
| 6 |
Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то: Прислать сообщение Error c ErrorCode = unknownXID. Прервать обработку InqReq |
| 7 | Сформировать PResPayloadSeq |
/p> Авторизация платежей продавца осуществляется согласно схеме, показанной на рис. 4.6.2.17.
Рис. 4.6.2.17. Авторизация платежей
Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр.
Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись.
После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты.
Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты.
При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса. Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель).
Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу.
Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись.
Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе.
Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты.
Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа. В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.
| Шаг | Действие |
| 1 | Сгенерировать AuthTags (см. табл. ниже) |
| 2 | Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI. |
| 3 | Сгенерировать AuthReqPayload (см. табл. ниже) |
| 4 |
Опционно для одновременной авторизации и резервирования заказа: Установить CaptureNow = TRUE Сгенерировать SaleDetail (см. табл. 4.6.2.47) Опционно занести в поле BatchID значение открытой в настоящее время платежной линии (серия платежей для данного клиента) для BrandAndBIN. Это значение должно быть ассоциировано с текущей транзакцией и BatchSequenceNumber (номер платежа). Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа. |
| 5 | Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken. |
| 6 | Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра. |
| 7 | Осуществить EncB-инкапсуляцию |
| 8 | Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы. |
| 9 | Поместить сообщение в цифровой конверт и отправить адресату |
/p> Процедура формирования AuthTags показана в таблице ниже.
| Шаг | Действие |
| 1 | Заполнить поле AuthRRTags (см. табл. 4.6.2.52) |
| 2 | Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID. |
| 3 | Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes |
| Шаг | Действие |
| 1 | Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE. |
| 2 | Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData |
| 3 | Установить AuthReqAmt равным числу авторизаций |
| 4 | Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты. |
| 5 | Если при некотором платеже необходимы данные MerchData, добавить их в сообщение. |
| 6 | Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки. |
| 7 | Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты. |
| 8 | Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение. |
| 9 | Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE. |
Таблица 4.6.2.64.
Структура AuthReq
AuthReq |
EncB(M, P, AuthReqData, PI) |
AuthReqData |
{AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]} |
PI |
См. табл. 4.6.2.39. |
AuthReqItem |
{AuthTags, [CheckDigests], AuthReqPayload} |
MThumbs |
Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца. |
CaptureNow |
Булева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация. |
SaleDetail |
См. табл. 4.6.2.47 |
AuthTags |
{AuthRRTags, TransIDs, [AuthRetNum]} |
CheckDigests |
{HOIData, HOD2} используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken |
AuthReqPayload |
См. табл. 4.6.2.65 |
AuthRRTags |
RRTags Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации. |
TransIDs |
Копируется из соответствующего поля OIData (см. табл. 4.6.2.59) |
AuthRetNum |
Идентификация запроса авторизации, используемого в пределах финансовой сети. |
HOIData |
DD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI. |
HOD2 |
DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI. |
/p> Структура данных AuthReqPayload представлена в таблице 4.6.2.65.
Таблица 4.6.2.65.
Структура AuthReqPayload
AuthReqPayload |
{SubsequentAuthInd, AuthReqAmt, [AVSData], [SpecialProcessing], [CardSuspect], RequestCardTypeInd, [InstallRecurData], [MarketSpecAuthData], MerchData, [ARqExtensions]} |
SubsequentAuthInd |
Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки |
AuthReqAmt |
Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие |
AVSData |
{[StreetAddress], Location} Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET. |
SpecialProcessing |
Числовое поле, указывающее тип запрошенной обработки |
CardSuspect |
Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения |
RequestCardTypeInd |
Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0). |
InstallRecurData |
См. табл. 4.6.2.41. |
MarketSpecAuthData |
< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth > Специфические авторизационные данные рынка |
MerchData |
{[MerchCatCode], [MerchGroup]} |
ARqExtensions |
Данные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты. |
StreetAddress |
Адрес улицы владельца карты |
MarketAutoAuth |
{Duration} |
MarketHotelAuth |
{Duration, [Prestige]} |
MarketTransportAuth |
{} В настоящее время нет авторизационных данных для этого сегмента рынка |
MerchCatCode |
4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца. |
MerchGroup |
Числовой код, идентифицирующий общую категорию продавца |
Duration |
Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture). |
Prestige |
Числовой тип приоритета, определяется платежной системы карты. |
/p> Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.
| Шаг | Действие |
| 1 | Извлечь запрос из транспортного сообщения |
| 2 | Дешифровать PI |
| 3 |
Сравнить TransIDs из AuthTags и PIHead или AuthToken: Проверить что коды XID идентичны Проверить что коды LID-C идентичны Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch |
| 4 |
Если PI является AuthToken: Обработать AuthToken В противном случае, если PI подписаны: Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch. Проверить PANData Запомнить данные из PANData В противном случае, если PI не подписаны: Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired Верифицировать хэш в EXH Запомнить данные из PANToken |
| 5 | Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed |
| 6 |
Обработать PIHead: Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension Запомнить данные от PIHead |
| 7 | Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch. |
| 8 | Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется. |
| 9 | Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported |
| 10 | Выполнить авторизацию через финансовую сеть платежной карты |
| 11 | Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты |
| 12 | Продолжить формирование сообщения AuthRes |
/p> Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.
| Шаг | Действие |
| 1 | Получить необходимые данные от авторизационного процесса |
| 2 | Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса. |
| 3 | Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел. |
| 4 |
Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра: Вставить Cert-PE в цифровой конверт PKCS#4 Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
| 5 | Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса |
| 6 | Заполнить поле PANToken, если это необходимо для сертификата продавца, |
| 7 |
Заполнить AuthResBaggage (опционно): Опционно заполнить CapToken Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE). Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью. |
| 8 | Опционно заполнить BatchStatus, как этого требует политика платежной системы карты. |
| 9 | Если PANToken имеется, реализовать EncBX-инкапсуляцию |
| 10 | Вставить сообщение в цифровой конверт и отправить владельцу карты |
| Шаг | Действие |
| 1 | Сгенерировать CapResPayload |
|
Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported |
|
| 3 | Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты. |
| 4 |
Заполнить ResponseData: Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса. Занести в AuthCharInd значение, присланное авторизационным процессом |
/p> Структура полей AuthRes представлена в таблице 4.6.2.66.
Таблица 4.6.2.66.
Структура полей AuthRes
AuthRes |
<EncB(P, M, AuthResData, AuthResBaggage), EncBX(P, M, AuthResData, AuthResBaggage, PANToken)> |
AuthResData |
{AuthTags, [BrandCRLIdentifier], [PEThumb], AuthResPayload} |
AuthResBaggage |
{[CapToken], [AcqCardMsg], [AuthToken]} |
PANToken |
См. табл. 4.6.2.46. Посылается, если сертификат продавца указывает на то, что информация предназначена продавцу. |
AuthTags |
Копируется из соответствующего AuthReq; TransIDs и AuthRetNum могут быть актуализованы с привлечением текущей информации |
BrandCRLIdentifier |
Список текущих CRL для всех СА в зоне ответственности СА платежной системы. |
PEThumb |
Оттиск сертификата расчетного центра предоставляется, если AuthReq.Mthumbs указывает то, что он нужен продавцу |
AuthResPayload |
См. табл. 4.6.2.67. |
CapToken |
См. табл. 4.6.2.44. |
AcqCardMsg |
Если владелец карты включил AcqBackKeyData в PIHead, расчетный центр может послать это поле продавцу в шифрованном сообщении для владельца карты. Продавец должен скопировать AcqCardMsg в любой последующий отклик PRes или InqRes, посылаемый владельцу карты. |
AuthToken |
Продавец использует это поле в качестве PI в последующих запросах AuthReq. См. табл. 4.6.2.42. |
Таблица 4.6.2.67
. Структура AuthResPayload
AuthResPayload |
{AuthHeader, [CapResPayload], [ARsExtensions]} |
AuthHeader |
{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]} |
CapResPayload |
Присылается, если CaptureNow имеет значение TRUE в AuthReq. См. табл. 4.6.2.71. |
ARsExtensions |
Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика. |
AuthAmt |
Копируется из AuthReqPayload.AuthReqAmt |
AuthCode |
Числовой код, индицирующий результат процесса авторизации |
ResponseData |
{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]} |
BatchStatus |
См. табл. 4.6.2.53. |
CurrConv |
{CurrConvRate, CardCurr} |
AuthValCodes |
{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]} |
RespReason |
Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется) |
CardType |
Числовой код, который указывает на тип карты, использованной для транзакции. |
AVSResult |
Числовой код отклика адресной верификационной службы |
LogRefID |
Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса) |
CurrConvRate |
Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты. |
AuthReqAmt |
Код валюты владельца карты в стандарте ISO 4217 |
ApprovalCode |
Код одобрения, присваиваемый транзакции эмитентом |
AuthCharInd |
Числовое значение, которое указывает условия, при которых выполнена авторизация. |
ValidationCode |
4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях. |
MarketSpecDataID |
Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью) |
/p> Список возможных значений кода AuthCode приведен ниже
| approved | Запрос авторизации удовлетворен |
| unspecifiedFailure | Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке. |
| declined | Запрос авторизации отклонен |
| noReply | Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента. |
| callIssuer | Эмитент запрашивает телефонный вызов от продавца |
| amountError | Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.) |
| expiredCard | Срок действия карты истек |
| invalidTransaction | Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым. |
| systemError | Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные. |
| piPreviouslyUsed | Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром). |
| recurringTooSoon | Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром). |
| recurringExpired | Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром) |
| piAuthMismatch | Дата в PI от владельца карты не согласуется с данными в OD от продавца. |
| installRecurMismatch | InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца. |
| captureNotSupported | Расчетный центр не поддерживает платеж (capture). |
| signatureRequired | Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы. |
| cardMerchBrandMismatch | Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра. |
/p> Обработка продавцом отклика AuthRes производится следующим образом.
| Шаг | Действие |
| 1 | Получить отклик из входного сообщения |
| 2 |
Извлечь запись транзакции и сравнить с AuthTags: Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID. |
| 3 | Если в сообщение включен BrandCRLIdentifier, запомнить CRL. |
| 4 | Обработать AuthResPayload |
| 5 | Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата |
| 6 | Если BatchStatus присутствует, обработать и запомнить данные. |
| 7 |
Обработать AuthResBaggage: Запомнить CapToken, если это поле присутствует Если имеется AcqCardMsg, запомнить его для отправки владельцу карты Запомнить AuthToken, если имеется, для последующей авторизации. Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken |
| 8 | Если присутствует PANToken, записать его в безопасную локальную память |
| 9 | Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку. |
| Шаг | Действие |
| 1 | Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется. |
| 2 |
Обрабатать CapResPayload: Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension Обработать CapCode с целью определения результата Обработать SaleDetail в соответствии с политикой платежной системы карты Для успешной оплаты заказа, записать CapCode и CapAmt. Если делался запрос оплаты (capture), будет возвращен CapResPayload |
| 3 | Если имеется CurrConv, запомнить его для переадресации владельцу карты |
| 4 |
Обработать AuthCode, AuthAmt и ResponseData: Для определения результата обрабатывается AuthCode. Запомнить AuthCode и AuthAmt для получения успешного результата. Запомнить ValidationCode для успешного исхода, если это поле имеется. Запомнить AuthValCode, если имеется. Запомнить AVSResult, если имеется. Запомнить LogRefID, если имеется. |
/p> Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode.
Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0).
При этом код отклика не переписывается.
Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode.
Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode.
Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации.
Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture). Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках.
Запрос/отклик платежа (CapReq/CapRes)
Пара сообщений CapReq/ CapRes предоставляет механизм выполнения платежа. Обмен этими сообщениями происходит между продавцом и расчетным центром. Транзакция обработки платежных запросов проходит через три состояния (см. рис. 4.6.2.18).
Рис. 4.6.2.18. Обработка платежных запросов
После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка.
Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов.
Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты.
После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу.
Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика. Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка.
Пары запросов CapReq/ CapRes предоставляют механизм завершения ранее авторизованного денежного платежа. Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.
| Шаг | Действие |
| 1 | Заполнить поле CapRRTags |
| 2 | Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken |
| 3 | Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier |
| 4 |
Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem: Заполнить TransIDs и AuthRRPID платежной позиций предшествующих сообщений в каждой транзакции. Заполнить CapPayload Заполнить SaleDetail, как это требует политика платежной системы карты. Если CapToken нет, или отсутствует авторизация в расчетном центре, копировать CapTokenItem из соответствующего AuthReqItem запроса AuthReq и из AuthResPayload отклика AuthRes |
| 5 | Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль. |
| 6 | В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken |
| 7 | Опционно заполняется CRqExtensions |
| 8 | Если включено PANToken, использовать EncBХ-инкапсуляцию |
| 9 | Если PANToken не включено, использовать EncB-инкапсуляцию |
| 10 | Вложить сообщение в цифровой конверт и послать владельцу карты |
| Шаг | Действие |
| 1 | Занести в поле CapDate текущее значение даты |
| 2 | Занести в CapReqAmt сумму выплаты |
| 3 | Скопировать AuthResPayload из соответствующего AuthRes |
| 4 | Опционно заполнить CPayExtensions |
Таблица 4.6.2.68
. Формат CapReq
CapReq |
<EncB(M, P, CapReqData, CapTokenSeq), EncBX(M, P, CapReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если имеется маркер PANToken, он должен соответствовать одному CapItem и одному CapToken в CapTokenSeq. |
CapReqData |
{CapRRTags, [MThumbs], CapItemSeq, [CRqExtensions]} |
CapTokenSeq |
{[ CapToken] +} Один или более CapTokens, соответствующие один-в-один CapItems в CapItemSeq. Любой CapToken может быть опущен, т.е. может равняться нулю. |
PANToken |
См. табл. 4.6.2.46. |
CapRRTags |
RRTags. Новый RRPID и Date |
MThumbs |
Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца. |
CapItemSeq |
{ CapItem +} Один или более CapItem в упорядоченном массиве |
CRqExtensions |
Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные в этом расширении относятся ко всем позициям запроса оплаты capture. Данные, относящиеся к специфическим позициям, должны помещаться в CapPayload |
CapToken |
Копируется из соответствующего AuthRes или AuthRevRes |
CapItem |
{TransIDs, AuthRRPID, CapPayload} |
TransIDs |
Копируется из соответствующего AuthRes или AuthRevRes |
AuthRRPID |
RRPID, который появляется в соответствующем AuthReq или AuthRev |
CapPayload |
См. табл. 4.6.2.69. |
Таблица 4.6.2.69
. Структура CapPayload
CapPayload |
{CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]} |
CapDate |
Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты. |
CapReqAmt |
Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты. |
AuthReqItem |
См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса. |
AuthResPayload |
См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика. |
SaleDetail |
См. табл. 4.6.2.47. |
CPayExtensions |
Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData. |
/p> Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.
| Шаг | Действие |
| 1 | Извлечь запрос из входного сообщения |
| 2 | Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension |
| 3 |
Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче: Обработать CapPayload Если CapToken присутствует: Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken Обработать TokenOpaque В противном случае, если допустимы платежи без CapToken: Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken Проверить TransIDs Извлечь запись транзакции Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLID f) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат. |
| Шаг | Действие |
| 1 | Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension |
| 2 | Запомнить SaleDetail |
| 3 |
Проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown. Если линия не открыта, отклонить платеж с CapCode = batchClosed |
| 4 | Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown. |
/p> Расчетный центр формирует отклик CapRes согласно следующему алгоритму.
| Шаг | Действие |
| 1 | Получить данные о платеже от платежного процесса |
| 2 | Скопировать CapRRTags из CapReq |
| 3 | Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел. |
| 4 |
Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE: Вложить Cert-PE в цифровой конверт PKCS#7 Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
| 5 | Опционно занести в поле BatchSequenceNum состояние текущих платежных линий |
| 6 | Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload |
| 7 |
Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом: Скопировать TransIDs из соответствующего CapReqItem Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется Заполнить CapResPayload |
| 8 | Опционно заполнить CRsExtensions |
| 9 | Вставить сообщение в цифровой конверт и послать продавцу |
| Шаг | Действие |
| 1 | Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem |
| 2 | Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem |
| 3 | Опционно заполнить CRsPayExtensions |
Таблица 4.6.2.70
. Структура CapRes
CapRes |
Enc(P, M, CapResData) |
CapResData |
{ CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]} |
CapRRTags |
RRTag >s; копируется из CapReq |
BrandCRLIdentifier |
Список текущих CRL для всех СА в области ответственности платежной системы СА. |
PEThumb |
Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается. |
BatchStatusSeq |
{BatchStatus +} |
CapResItemSeq |
{CapResItem +} Заказ соответствует CapReq |
CRsExtensions |
Данные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег. |
BatchStatus |
См. табл. 4.6.2.53. |
CapResItem |
{TransIDs, AuthRRPID, CapResPayload} |
TransIDs |
Копируется из соответствующего CapReq |
AuthRRPID |
RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq |
CapResPayload |
См. табл. 4.6.2.71. |
/p> Структура данных CapResPayload представлена в таблице 4.6.2.71.
Таблица 4.6.2.71
. Структура CapResPayload
CapResPayload |
{CapCode, CapAmt, [BatchID], [BatchSequenceNum], [CRsPayExtensions]} |
CapCode |
Цифровой код, указывающий на состояние платежа |
CapAmt |
Копируется из соответствующего CapReq |
BatchID |
Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq |
BatchSequenceNum |
Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq |
CRsPayExtensions |
Данные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег. |
| Шаг | Действие |
| 1 | Извлекается отклик из входного сообщения |
| 2 | Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается |
| 3 |
Извлекается запись транзакции и производится сравнение CapRRTags: Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID |
| 4 | Если в сообщение включен BrandCRLIdentifier, запомнить все CRL. |
| 5 | Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата. |
| 6 |
Для каждого CapResItem в CapResSeq: Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается. Обработать CapCode для получения результата операции Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID. |
| 7 | Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus |
/p> В таблице ниже представлены допустимые значения CapCode.
| success | Платежная позиция обработана расчетным центром успешно |
| unspecifiedFailure | Причина неудачи неизвестна |
| duplicateRequest | Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID) |
| authExpired | Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты. |
| authDataMissing | В платежном запросе отсутствует авторизационная информация |
| invalidAuthData | Авторизационная информация для данной транзакции некорректна |
| capTokenMissing | Для обработки данной позиции необходимо поле CapToken, а его нет |
| invalidCapToken | Поле CapToken некорректно для данной транзакции |
| batchUnknown | Расчетный центр не знает о существовании платежной линии для данной позиции |
| batchClosed | Платежная линия для данной позиции закрыта |
| unknownXID | Не распознан идентификатор XID |
| unknownLID | Не распознан идентификатор LID |
| Шаг | Действие |
| 1 | Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой. |
| 2 | Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром. |
| 3 |
Заполнить одну или более позиций в CredRevOrCredReqItems: Скопировать TransIDs из соответствующего CapRes. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq). Заполнить NewBatchID, если кредитная линия транзакции закрыта. Заполнить CapRevOrCredReqData с текущей датой и временем Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken. Опционно заполнить CRvRqItemExtensions |
| 4 | Опционно заполнить CRvRqExtensions |
/p> Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72.
Таблица 4.6.2.72
. Структура CapRevOrCredReqData
CapRevOrCredReqData |
{CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]} |
CapRevOrCredRRTags |
RRTags. Новый идентификатор RRPID и Date для данной пары. |
MThumbs |
Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца |
CapRevOrCredReqItemSeq |
{CapRevOrCredReqItem +} Один или более CapRevOrCredReqItem в виде упорядоченного массива |
CRvRqExtensions |
Данные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом. |
CapRevOrCredReqItem |
{TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]} |
TransIDs |
Копируется из соответствующего CapRes. Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса |
CapPayload |
См. табл. 4.6.2.69 |
NewBatchID |
Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию. |
CapRevOrCredReqDate |
Дата подачи запроса |
CapRevOrCredReqAmt |
В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload |
NewAccountInd |
Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца. |
CRvRqItemExtensions |
Данные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром |
/p> Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.
| Шаг | Действие |
| 1 | Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается. |
| 2 |
Обрабатывается каждое CapRevOrCredItem: Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown. Запоминается CapRevOrCredAmt Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети. |
| 3 | На основе TransIDs в AuthRevTags извлекается запись транзакции. |
| Шаг | Действие |
| 1 | Заполнить поле CapRevOrCredTags |
| 2 | Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел. |
| 3 |
Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то: Ввести Cert-PE в цифровой конверт PKCS#7 Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью |
| 4 | Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено. |
| 5 |
Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом: Скопировать TransIDs из соответствующего CapRevOrCredReqItem Если доступно, скопировать RRPID из соответствующего CapRevOrCredItem Заполнить CapRevOrCredResPayload следующим образом: Занести в CapRevOrCredCode результат кредита или отзыва платежа Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem Опционно заполнить CRvRsPayExtensions |
| 6 | Опционно заполнить CRvRsExtensions |
/p> Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73.
Таблица 4.6.2.73
. Структура CapRevOrCredResData
| CapRevOrCredResData |
{CapRevOrCredRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions] |
| CapRevOrCredRRTags | RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData |
| BrandCRLIdentifier | Список текущих CRL для всех СА в зоне ответственности СА платежной системы. |
| PEThumb | Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается |
| BatchStatusSeq | {BatchStatus +} |
| CapRevOrCredResItemSeq |
{CapRevOrCredResItem +} Один или более CapRevOrCredResItem в упорядоченном массиве |
| CRvRsExtensions | Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром |
| BatchStatus | См. табл. 4.6.2.53. |
| CapRevOrCredResItem | {TransIDs, AuthRRPID, CapRevOrCredResPayload} |
| TransIDs | Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags |
| AuthRRPID | RRPID, который появляется в соответствующем AuthReq или >AuthRevReq |
| CapRevOrCredResPayload | См. табл. 4.6.2.74 |
Таблица 4.6.2.74
. Структура CapRevOrCredResPayload
| CapRevOrCredResPayload | {CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]} |
| CapRevOrCredCode | Числовой код, характеризующий состояние отзыва платежа или кредита. |
CapRevOrCredActualAmt |
Копируется из соответствующего CapRevOrCredReqItem. |
BatchID |
Идентификатор платежной линии сделки для банка продавца |
BatchSequenceNum |
Порядковый номер позиции в последовательности платежей |
CRvRsPayExtensions |
Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит. |
/p> Допустимые значения кода CapRevOrCredCode представлены ниже
| success | Позиция была успешно обработана расчетным центром |
| unspecifiedFailure | Причина неудачи не специфицирована |
| duplicateRequest | Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID) |
| originalProcessed | Запрос платежа для данной позиции был уже обработан |
| originalNotFound | Специфицированная позиция расчетным центром не обнаружена |
| capPurged | Информация о платеже была удалена из памяти транзакций расчетного центра |
| missingCapData | Информация о платеже отсутствует в запросе отзыва платежа или кредита |
| missingCapToken | Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита |
| invalidCapToken | Маркер CapToken некорректен |
| batchUnknown | Платежная линия для данной позиции расчетному центру неизвестна |
| batchClosed | Платежная линия для данной позиции уже закрыта |
| Шаг | Действие |
| 1 | Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension. |
| 2 | Обработать CapRevOrCredTags |
| 3 |
Извлечь запомненную запись транзакции и обработать TransIDs следующим образом: Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. |
| 4 | Если в сообщение включен BrandCRLIdentifier, запомнить CRL. |
| 5 | Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата. |
| 6 | Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат |
| 7 |
Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. Обработать CapRevOrCredPayload следующим образом: Обработать CapRevOrCredCode для получения результата Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt Обработать BatchID и BatchSequenceNum, если таковые имеются |
/p> Пара сообщений CapRevReq/ CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75.
Таблица 4.6.2.75
. Структура CapRevReq
| CapRevReq |
<EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq |
| CapRevData | CapRevOrCredReqDat a |
| CapTokenSeq |
{[CapToken] +} Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL) |
| PANToken | См. табл. 4.6.2.46 |
| CapToken | Копируется из соответствующего AuthRes или AuthRevRes |
| CapRevRes | Enc(P,M, CapRevResData) |
| CapRevResData | CapRevOrCredResData |
| Шаг | Действие |
| 1 | Генерируется информация CredReqData |
| 2 |
Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом: Если доступно, записать CapToken для соответствующей транзакции. В противном случае (если недоступно), записать NULL. Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq |
| 3 |
Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq |
| 4 | Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию. |
| 5 | Вставить сообщение в цифровой конверт и послать владельцу карты |
/p> Структура запроса CredReq показана в таблице 4.6.2.76.
Таблица 4.6.2.76.
Структура CredReq
| CredReq | < EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS |
| CredReqData | CapRevOrCredReqData ; см. табл. 4.6.2.72. |
| CapTokenSeq |
{[CapToken] +} Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL |
| PANToken | См. табл. 4.6.2.46 |
| CapToken | Копируется из соответствующего AuthResили AuthRevRes |
| Шаг | Действие |
| 1 | Извлекается запрос из входного сообщения |
| 2 |
Для каждой позиции, для которой продавец получил маркер CapToken: Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing Проверяется CapToken |
| 3 | Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem. |
| Шаг | Действие |
| 1 | Получить отклик из финансовой сети платежной карты |
| 2 | Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе |
| 3 | Включить Enc-инкапсуляцию для полученных результатов |
| 4 | Поместить сообщение в цифровой конверт и отправить владельцу карты |
| CredRes | Enc(P, M, CredResData) |
| CredResData | CapRevOrCredResData ; см. табл. 4.6.2.74. |
Получается отклик CredRes из входного сообщения
Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму.
Сообщения CredRevReq/CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита. Формирование запроса CredRevReq осуществляется следующим образом.
| Шаг | Действие |
| 1 | Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq |
| 2 |
Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом: Если доступен, занести CapToken для соответствующей транзакции В противном случае, если маркер не доступен, записать NULL |
| 3 |
Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq. |
| 4 | Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию. |
| 5 | Вставить сообщение в цифровой конверт и направить владельцу карты |
Таблица 4.6.2.77. Структура CredRevReq
| CredRevReq |
<EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq. |
| CredRevReqData | CapRevOrCredReqData; см. табл. 4.6.2.72 |
| CapTokenSeq |
{[CapToken] +} Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой CapToken может быть опущен, т.е. может быть NULL |
| PANToken | См. табл. 4.6.2.46 |
| CapToken | Копируется из соответствующего AuthRes или AuthRevRes |
| Шаг | Действие |
| 1 | Выделить запрос из входного сообщения |
| 2 |
Для каждой позиции, для которой продавец получил CapToken: Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing Проверить CapToken |
| 3 | Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem |
/p> Формирование отклика CredRevRes осуществляется в следующей последовательности.
| Шаг | Действие |
| 1 | Получить отклик из финансовой сети платежной карты |
| 2 | Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе. |
| 3 | Включить для полученного результата Enc-инкапсуляцию |
| 4 | Вложить отклик в цифровой конверт и отправить владельцу карты |
CredRevRes |
Enc(P, M, CredRevResData) |
CredRevResData |
CredRevOrCredResData; См. табл. 4.6.2.74. |
| Шаг | Действие |
| 1 | Извлекается отклик из входного сообщения |
| 2 | Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа. |
| Шаг | Действие |
| 1 | Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52. |
| 2 | Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра. |
| 3 |
Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты: Заполнить поле BrandID Опционно заполнить поле BIN |
| 4 | Опционно заполнить поле PCRqExtensions |
| 5 | Ввести S (см. описание оператора подпись выше) |
| 6 | Вложить сообщение в цифровой конверт и отправить владельцу карты |
/p> Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.
| PCertReq | S(M, PCertReqData) |
| PCertReqData | {PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]} |
| PCertTags |
RRTags. Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата |
| MThumbs | Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца. |
| BrandAndBINSeq |
{BrandAndBIN +} Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs |
| PCRqExtensions | Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации |
| BrandAndBIN | {BrandID, [BIN]} |
| BrandID | Платежная система карты (без указания типа). |
| BIN | Идентификационный номер банка для обработки транзакции продавца в расчетном центре. |
Таблица 4.6.2.78
. Структура сообщения PCertReq
Расчетный центр обрабатывает PCertReq следующим образом
| Шаг | Действие |
| 1 | Расчетный центр получает PCertReq из входного сообщения |
| 2 | Обрабатываются расширения PCRqExtensions. Если встречается нераспознанное расширение, помеченное как критическое, прислается отклик unrecognizedExtensions, а PCertReq отбрасывается. |
| 3 | Обрабатывается BrandIDSeq и MThumbs |
| 4 | Формируется и посылается PCertRes |
| Шаг | Действие |
| 1 | Скопировать PCertTags из PCertReq в PCertRes |
| 2 |
Для каждого BrandAndBIN в BrandIDSeq из PCertReq: Если доступен корректный сертификат: Заполнить соответствующий сертификат шифрования расчетного центра Cert-PE Занести в PCertCode, соответствующий PCertResItem c “успешным” кодом PCertCode Занести в CertThumb оттиск присланного сертификата В противном случае, если сертификаты недоступны, так как не поддерживается данная платежная система, занести PCertCode, соответствующего PСertResItem c кодом PCertCode = brandUnsupported и опустить CertThumb В противном случае, если платежная система поддерживается, но BIN неизвестен, занести в поле PCertCode соответствующего PсertResItem код PCertCode = unknownBIN и опустить CertThumb В противном случае занести в поле PCertCode соответствующего PCertResItem код PCertCode = unspecifiedFailure и опустить CertThumb |
| 3 | Для каждой платежной системы, для которой необходим сертификат, прислать текущее значение BrandCRLIdentifier, если только Mthumbs не содержит оттиска для текущего BrandCRLIdentifier |
| 4 | Опционно заполнить PCRqExtensions |
/p> Структура сообщения-отклика PCertRes представлена в таблице 4.6.2.79.
Таблица 4.6.2.79.
Структура PCertRes
| PCertRes | S(P, PCertResTBS) |
| PCertResTBS | {PCertTags, [BrandCRLIdentifierSeq], PCertResItems, [PCRsExtensions]} |
| PCertTags | RRTag s; копируется из PCertReq. |
| BrandCRLIdentifierSeq | {BrandCRLIdentifier +} |
| PCertResItems |
{PCertResItem +} Один или более статусных кодов и оттисков сертификатов, которые возвращаются в соответствии один к одному с PCertReq.BrandAndBINSeq |
| PCRsExtentions | Сертификатный отклик расчетного центра не шифруется, по этой причине данное расширение не должно содержать конфиденциальных данных. |
| BrandCRLIdentifier | Список текущих CRL для всех CA в зоне ответственности CA платежной системы. См. раздел о BrandCRLIdentifier |
| PCertResItem | {PCertCode, [CertThumb]} |
| PCertCode | Цифровой код, указывающий результат PCertReq |
| CertThumb | Оттиск возвращенного сертификата |
| Шаг | Действие |
| 1 | Извлекается отклик из входного сообщения |
| 2 | Обрабатываются PCRsExtensions. Если встречается нераспознанное расширение, помеченное как критическое, присылается отклик unrecognizedExtensions и отбрасывается PCertRes |
| 3 | Извлекаются сертификаты из Cert-PE |
| 4 | Проверяются сертификаты в Cert-PE путем сравнения их с CertThumbs в PCertResItems. Отбрасываются все сертификаты, которые не прошли сверку. |
| 5 | Обработатывается каждый BrandCRLIdentifier из присланной последовательности таких идентификаторов. |
| 6 | Продолжается обработка сообщений, которые ожидали сертификатов, присланных в PCertRes. |
Таблица 4.6.2.80
. Значения PCertCode
| success | Запрос обработан успешно |
| unspecifiedFailure | Запрос не прошел из-за неспецифицированной причины |
| brandNotSupported | Запрос не прошел из-за того, что платежная система, специфицированная в PCertReq, не поддерживается |
| unknownBIN | Запрос не прошел из-за того, что BIN, специфицированный в PCertReq, не поддерживается. |
/p>
Управление платежными линиями (Batch)
Продавец посылает запросы управления платежными линиями расчетному центру для того, чтобы осуществлять контроль над последовательностями платежей расчетных транзакций. Операция управления платежной линией включает в себя обмен двумя сообщениями BatchAdminReq (запрос продавца в расчетный центр) и BatchAdminRes (отклик расчетного центра). Запрос может включать в себя инструкции открыть, очистить или закрыть платежную линию, а также передать или запросить информацию о состоянии платежной линии. Отклик несет в себе информацию о состоянии или запрошенные данные.
Платежная линия формируется расчетным центром, когда продавец открывает ее для накопления транзакций и сумм. Все транзакции, которые проплачиваются, объединяются в специфическую группу (платежную линию - batch) или группу по умолчанию, если не определена специальная платежная линия (группа платежей). Следует учитывать, что в группу платежей могут входить операции, выполненные в рамках различных платежных систем. Поддержка групп платежей позволяет продавцу и расчетному центру улаживать проблемы, связанные с различными несогласованностями.
Если продавец контролирует содержимое групп платежей, каждая платежная линия открывается прежде, чем транзакции ассоциируются с ней путем включения BatchID и BatchSequenceNum в платежные транзакции. Продавец может также закрыть платежную линию в соответствии с требованиями бизнеса. Транзакции не ассоциируются с платежной линией после ее закрытия. Продавец может также иметь возможность удалить все транзакции из открытой платежной линии. Очистка платежной линии не означает ее закрытия.
Если содержанием платежных линий управляет расчетный центр, продавец не должен вставлять BatchID и BatchSequenceNum в платежные транзакции. Открытие и закрытие платежной линии контролируется в этом случае расчетным центром, который может включать BatchID и BatchSequenceNum в возвращаемую структуру SaleDetail. Продавец при этом не может удалять транзакции из группы или закрывать платежные линии, определенные идентификаторами BatchID, сформированными расчетным центром. Продавец может запросить статусную информацию для любой платежной линии, которая имеет известный BatchID. Расчетный центр возвращает BatchStatus для запрошенной платежной линии. Продавец может запросить BatchStatus для определенных платежных систем или итоговый баланс для конкретной платежной линии.
Если продавец управляет содержимым платежной линии, тогда он может предоставлять информацию BatchStatus расчетному центру для любого BatchID. Расчетный центр проверяет данные, предоставленные продавцом в BatchStatus путем сверки с информацией, накопленной у него. При этом продавец получит отклик, в котором будет отражено соответствие этих сумм.
Если продавец предоставляет информацию о транзакции расчетному центру, последний выдает состояние серии платежей в отклике BatchAdminRes, который следует за BatchAdminReq. Продавец формирует запрос BatchAdminReq в следующем порядке.
| Шаг | Действие |
| 1 | Если это первое сообщение, направленное расчетному центру после получения нового секретного ключа, или если это первое сообщение в данный день, в цифровой конверт этого сообщения следует вложить сертификаты для секретных ключей и цепочку сертификатов платежной системы, выбранных продавцом для подписи и шифрования сообщений BatchAdmin. |
| 2 | Сформировать RRTags |
| 3 |
Если новая платежная линия открыта: Установить BatchOperation = open Занести в поле BatchID идентификатор для неиспользуемой платежной линии. Опционно занести в поле BrandAndBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые могут появиться в данной группе платежей. Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения |
| 4 |
Если платежная линия (группа платежей) пуста: Установить BatchOperation = purged Занести в BatchID идентификацию для неиспользуемой платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы платежей. Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения |
| 5 |
Если платежная линия закрыта: Установить BatchOperation = closed Занести в BatchID идентификацию для открытой платежной линии Установить ReturnBatchSummeryIndicator = FALSE Опустить все остальные поля сообщения |
| 6 |
Если нужно запросить состояние платежной линии у расчетного центра: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить объем статусной информации, возвращаемой в BatchAdminRes. Установить ReturnBatchSummeryInd = TRUE Опустить все остальные поля сообщения |
| 7 |
Если нужно запросить детальные данные о платежной линии у расчетного центра: Опустить BatchOperation Занести в BatchID идентификацию платежной линии Опционно занести в BrandandBIN последовательность BrandID и опционно BIN, чтобы ограничить список транзакций, которые удаляются из группы (платежной линии). Если необходима итоговая информация платежной линии, установить ReturnBatchSummeryInd = TRUE, в противном случае = FALSE Если это первый (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить StartingPoint равным значению NextSequence, полученному в предшествующем отклике BatchAdminRes для данной последовательности. Занести MaximumItems наибольший номер позиции, которую нужно послать в BatchAdminRes Опустить все остальные поля сообщения |
| 8 |
Если нужно послать состояние платежной линии расчетному центру: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опустить BrandandBIN Установить ReturnBatchSummeryInd = FALSE Сформировать BatchStatus: Занести в поле BatchTotals значения для всех транзакций данной группы (batch) Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии. f) Опустить все остальные поля сообщения |
| 9 |
Если нужно передать расчетному центру детальные данные о платежной линии: Опустить BatchOperation Занести в BatchID идентификацию для платежной линии Опустить BrandandBIN Установить ReturnBatchSummeryInd = FALSE Если это последний (или единственный) запрос в последовательности, установить StartingPoint =0, в противном случае установить NextStartingPoint равным значению, позволяющему расчетному центру проверить, что группа платежей принята в правильной последовательности. Заполнить TransactionDetail для набора позиций платежной линии. Если NextStartingPoint = 0, опционно сформировать BatchStatus: Занести в BatchTotals значения для всех транзакций платежной линии. Опционно занести BrandID и BatchTotals в BranchBatchDetails для одной или более платежных систем, используемых в рамках платежной линии. h) Если продавец хочет прервать передачу BranchBatchDetails, установить значение поля MaximumItem равным 0, в противном случае опустить это поле. |
| 10 | Реализовать операцию подписи для результата шагов 1-9, используя сертификат подписи продавца для любой платежной системы, известной расчетному центру. |
| 11 | Включить сертификат шифрования продавца для той же платежной системы, что была выбрана на предшествующем шагу. Общедоступный ключ этого сертификата будет использоваться расчетным центром при дешифровке сообщений BatchAdminRes. |
| 12 | Зашифровать BatchAdminReqTBE, используя сертификат расчетного центра и установить тип содержимого равным id-set-content-BatchAdminReqTBE. |
| 13 | Вложить сообщение в цифровой конверт и послать владельцу карты |
/p> Структура запроса BatchAdminReq представлена в таблице 4.6.2.81.
Таблица 4.6.2.81
. Структура BatchAdminReq
| BatchAdminReq | Enc(M, P, BatchAdminReqData) |
| BatchAdminReqData | {BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]} |
| BatchAdminRRTags |
RRTags. Новый идентификатор RRPID и Date (дата) |
| BatchID | Идентификатор платежной линии для счета банка продавца |
| BrandAndBINSeq | {BrandAndBIN +} |
| BatchOperation | Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии |
| ReturnBatchSummaryInd | Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные. |
| ReturnTransactionDetail |
{StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]} Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты. |
| BatchStatus | См. табл. 4.6.2.53. |
| TransDetails | {NextStartingPoint, TransactionDetailSeq} |
| BARqExtensions | Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов. |
| BrandAndBIN | {BrandID, [BIN]} |
| StartingPoint | Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes |
| MaximumItems | Максимальное число позиций, которые следует прислать в этой группе. |
| ErrorsOnlyInd | Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки. |
| BrandID | Тип платежной системы (без указания типа продукта). |
| NextStartingPoint | Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций. |
| TransactionDetailSeq | {TransactionDetail +} |
| BIN | Идентификационный номер банка для обработки транзакций продавца. |
| TransactionDetail | См. табл. 4.6.2.54 |
| Шаг | Действие |
| 1 | Выделить запрос из входного сообщения |
| 2 | Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure. |
| 3 | Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID. |
| 4 |
Если BatchOperation = open: Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется BrandIDSeq: Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии. Открыть платежную линию для использования продавцом и установить BAStatus = success. Продолжить процесс посылкой BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open. |
| 5 |
Если BatchOperation = purge: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Если BrandIDSeq присутствует: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN. В противном случае, удалить все транзакции из группы платежей Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge. |
| 6 |
Если BatchOperation = close: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close. |
| 7 |
Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если BrandAndBIN включен: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу. NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE. |
| 8 |
Если включено поле StartingPoint: Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint. Если имеется BrandAndBIN: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd. f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes |
| 9 |
Если код BatchOperation опущен, а BatchStatus имеется: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется поле BrandBatchDetails: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes |
| 10 |
Если код BatchOperation опущен и включено поле TransactionDetails: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Последовательность BrandAndBIN игнорируется. |
/p> Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.
| Шаг | Действие |
| 1 | Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом. |
| 2 | Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData. |
| 3 | Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE. |
| 4 | Вложить сообщение в цифровой конверт и послать владельцу карты. |
Таблица 4.6.2.82
. Структура BatchAdminRes
BatchAdminRes |
Enc(P, M, BatchAdminResData) |
BatchAdminResData |
{BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]} |
BatchAdminTags |
RRTags; копируется из предшествующего BatchAdminReq |
BatchID |
Идентификатор платежной линии между продавцом и его банком. |
BAStatus |
Числовой код, указывающий на состояние открытой платежной линии. |
BatchStatus |
См. табл. 4.6.2.53. |
TransmissionStatus |
Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня |
SettlementInfo |
{SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate} |
TransDetails |
{NextStartingPoint, TransactionDetailSeq} |
BARsExtensions |
Данные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail. |
SettlementAmount |
Занесенная через сеть на счет продавца сумма |
SettlementType |
Числовой код, указывающий тип суммы |
SettlementAccount |
Счет продавца |
SettlementDepositDate |
Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца |
NextStartingPoint |
Нуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение |
TransactionDetailSeq |
{TransactionDetail +} |
TransactionDetail |
См. табл. 4.6.2.54.. |
/p> В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID
| unspecified | Неизвестное значение |
| standard | Стандартная скорость обмена |
| keyEntered | Скорость обмена для транзакций key-entered (ввод с клавиатуры) |
| electronic | Скорость обмена для электронных транзакций |
| additionalData | Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные |
| enhancedData | Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации). |
| marketSpecific | Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт). |
| Шаг | Действие |
| 1 | Извлекается отклик BatchAdminRes из входного сообщения. |
| 2 | Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed. |
| 3 | Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID. |
| 4 | Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны. |
| 5 | Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы. |
| 6 | Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin. |
| 7 | Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца. |
/p> Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet (http://www.microsoft.com/commerce/wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$.
Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash (http://www.digicash.nl) или Millicent -
http://www.millicent.digital.com/). Схема First Virtual (http://www.fv.com) предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон.
Система CyberCash (http://www.cybercash.com) базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши “оплатить”. Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций.
Сетевая безопасность
6 Сетевая безопасность
Семенов Ю.А. (ГНЦ ИТЭФ)
Совсем недавно персональная ЭВМ стоила в России дороже автомашины, сегодня же десятки (а может быть и сотни) тысяч ЭВМ работают дома, развлекая и зарабатывая деньги своим хозяевам. Сети ЭВМ из достояния научных центров постепенно стали обязательным атрибутом процветающих торговых фирм, банков, милиции, таможни, налоговые службы и т.д. Если раньше главной проблемой было создание сети и обеспечение доступа к Интернет, то сегодня по мере увеличения размеров сети проблема безопасности выходит на лидирующие позиции. Безопасность - комплексное понятие, это и ограничение нежелательного доступа, и сохранность информации, и живучесть самой сети. Актуальность проблемы подтверждает количество RFC-документов, опубликованных за последнее время [1-14, 18] по данной тематике (см. библиографию в конце данного раздела). Эту статью следует рассматривать как обзор возможных угроз и способов защиты. В основном это касается обычных сетей, не содержащих конфиденциальную или тем более секретную информацию. Но многие соображения, приводимые здесь, носят достаточно универсальный характер.
Существуют юридические аспекты сетевой безопасности, организационные и программно-технические. Здесь будут рассмотрены два последних, тем более что следование букве закона не относится к числу главных добродетелей программистов. Рассмотрим сначала факторы, влияющие на надежность сети. Источниками ненадежности сети могут быть:
стихийные явления, к которым можно отнести отказы оборудования или питания, а также некомпетентность обслуживающего персонала;
несанкционированные действия операторов удаленных ЭВМ.
Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли, и спросить не с кого. Начинать надо с того, что в вашей власти, а это, прежде всего, правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (uninterruptable power supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При выборе UPS нужно учесть суммарную потребляемую мощность оборудования, подключаемого к источнику питания, и время, в течение которого UPS способен работать без напряжения в сети. При этом главная задача UPS - обеспечение завершения операций обмена с диском до того, как произойдет полное обесточивание сервера, или когда будет произведено переключение на резервный канал питания. Это осуществимо при использовании специального интерфейса и соответствующего программного обеспечения, работающего согласно протоколу SNMP. Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.
С использованием нанотехнологии фирма IBM разработала запоминающее устройство с плотностью записи данных 1 Терабит на квадратный дюйм. Это позволяет записать 25 миллионов страниц или 25 DVD дисков на площади одной почтовой марки. Система использует тысячи сверх тонких иголок из кремния, которые служат для формирования миниатюрных углублений в тонкой синтетической пленке. Вершины иголок имеют размер нескольких атомов (диаметр ? 10нм). Технология допускает перезапись.Внедрение этой технологии на какое-то время решит проблему.
Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа exabyte емкостью 2.5-20 Гбайт достаточно широко используются, но относительно высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи для них не слишком высока). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более.
К сожалению, помимо объективных причин на надежность и устойчивость работы сети влияет и субъективный фактор. Это, прежде всего некомпетентный персонал, различные компьютерные вирусы и хакеры. Скрытая безработица среди высоко квалифицированных программистов способствует распространению хакерства в России. Практическое отсутствие сетевых вирусов связано с ограниченностью сетей в России и со сложностью их написания, но этот барьер будет скоро преодолен и к этому следует готовиться уже сегодня. Еще в декабре 1994 года я получил предупреждение о распространении сетевых вирусов (good times и xxx-1) по Интернет:
“there are two virus infected messages circulated in the internet.
one is called "good times" and the other "xxx-1".
do not read !! do not download !!! delete right away !!!!”
(Не читайте!! Не загружайте!!! Немедленно уничтожайте!!!!)
Или еще один более свежий пример
"if you receive an email titled "it takes guts to say jesus" do not open it. it will erase everything on your hard drive. this information was announced yesterday morning from ibm; aol states that this is a very dangerous virus, much worse than "melissa," and that there is no remedy for it at this time."
ЭВМ, подключенная к сети, потенциально всегда уязвима. Есть сообщения о вирусе cascade в сетях Novell, созданы вирусы, переносимые с помощью электронной почты (например, вирусы, базирующиеся на макросах WinWord), и т.д. Последние наиболее опасны, так как, проглядывая какое-то очередное сообщение, содержащее приложение (attachment), клиент может и не предполагать, какую угрозу это таит. Макро-вирус может выполнять функцию "троянского коня". Тривиальным и одновременно крайне полезным советом является рекомендация стирать, не читая, сообщения, содержащие исполняемое приложение, даже если это сообщение получено от вашего хорошего знакомого (это может быть рассылка, выполняемая мактро-вирусом, через его адресную книгу). Если есть сомнения, позвоните вашему знакомому, или пошлите ему mail, прежде чем читать подозрительное послание.
Троянский конь. К этой категории относят две разновидности объектов. Один из них – программа, засылаемая в атакуемый узел, которая осуществляет перехват всего ввод с терминала, записывает эти данные в файл и позднее пересылает этот файл “хозяину этого коня”. Другой объект является пассивным, выглядит безопасным и привлекательным. Например, находится в каталоге FTP-депозитария games и выглядит как игра. Легковерный клиент может скопировать такой файл и попытаться его запустить. Результатом может стать уничтожение содержимого жесткого диска.
Кролики. Это программы, которые быстро размножаются в памяти или на диске, поглощая ресурсы ЭВМ, что может привести к повисанию или разрушению операционной системы. Сами по себе эти программы, как правило, не несут в себе разрушительных функций.
Черви. Программы, напоминающие “кроликов”, но способные перемещаться по сети Интернет от одного узла к другому (узлы должны иметь идентичную операционную среду).
Макро вирусы. Вирусы, базирующие на макросах таких систем, как excel или winword. Опасность таких вирусов заключается в том, что они могут разноситься электронной почтой, когда соответствующие файлы подсоединены к почтовому сообщению. Попытка просмотра текста excel или winword приводит к заражению ЭВМ этим вирусом. После чего такая машина может стать сама разносчиком вируса. Из-за простоты заражения этот тип вируса в настоящее время наиболее опасен. Кроме того, он может иметь все свойства "троянского коня", что усугубляет опасность.
Все перечисленные программы создавались людьми специально для нанесения вреда, их мотивации предмет изучения психологов и социологов. Но есть потенциально опасные объекты, специально не создаваемые для нанесения вреда. Это, прежде всего, программы, разработанные не профессионалами и не лишенные ошибок. Следует иметь в виду, что любая ошибка в программе опасна сама по себе, но она может стать объектом атаки хакера. По этой причине бездумное использование не сертифицированных программ несет в себе достаточно высокий уровень риска.
Существуют и другие угрозы, например, так называемая “Молдавская связь”. Суть этой уловки, использованной впервые одним из провайдеров в Молдове, заключается в том, что в каком-то депозитарии или web-странице приводится ссылка на некоторый привлекательный объект, например набор эротических картинок. Но для их просмотра предлагается скопировать себе специальную программу. При запуске оговоренной программы канал связи с местным провайдером разрывается и устанавливается связь через модем с другим удаленным провайдером. Это особенно опасно для людей, подключенных к Интернет через модем, так как может стоить им многие сотни долларов за пользование междугородним телефоном.
Многие современные просмотрщики файлов (viewer) и вставные программы (plug-in), предоставляя определенные удобства, несут в себе ощутимые угрозы безопасности. Мало того, что они являются достаточно часто разносчиками вирусов, некоторые из них снабжены интерпретаторами команд. Такие интерпретаторы встраиваются, например, для создания справочной системы, но хакер может ввести туда свои, нужные только ему команды. А некоторые команды могут, скажем, разметить ваш диск. Подводя итоги, можно сказать, что всякая программа, имеющая макро процессор, потенциально опасна. По этой же причине следует избегать применения редактора emacs (UNIX) в качестве внешнего просмотрщика. Опасна и любая программа, способная запустить внешнее приложение. Примером такой программы можно назвать microsoft powerpoint, которая допускает во время презентации запуск любого приложения. Конфигурируя свою систему windows, не желательно объявлять powerpoint в качестве просмотрщика. И чем меньше программ просмотрщиков в системе, тем лучше для ее здоровья.
Современные WEB-серверы довольно широко используют java-аплеты. При этом должны строго выполняться определенные правила.
Аплеты не могут читаться с или писаться на локальный диск.
Аплеты не должны иметь доступа к локальным внешним физическим устройствам.
Аплеты не должны иметь доступа к конфигурационной информации системы, включая ту, которая позволила бы им узнать с какой ОС они имеют дело.
Аплеты не должны исполнять системных команд или запускать внешние программы.
Аплеты не должны устанавливать сетевые соединения с машинами, кроме той, с которой они загружены.
Если все эти условия выполняются, аплеты совершенно безопасны, но контролировать это желательно.
При создании протоколов Интернет в начале 80-х годов авторы мало думали о безопасности. Предполагалось, что пользоваться сетью будут исключительно ответственные и добропорядочные люди. Но людям, к сожалению, свойственно преувеличивать свои положительные качества. Реальность оказалась не столь позитивна. Сказалась и любовь получать что-то бесплатно и врожденный разрушительный потенциал. Некоторые приемы хакеров описаны в разделе, посвященном протоколу TCP. Рассмотрим, что может произойти, если будет получен TCP-сегмент с битами SYN и FIN, равными 1. При получении такого сегмента TCP осуществляет переход в состояние close_wait. Если до этого не было установлено соединений, переход в это состояние не должен производиться, но большинство реализаций выполняют его. Такой переход крайне не желателен, так как в этом состоянии не работает таймер и система останется в нем вечно.
Другой вид атак протокола TCP называется “syn flooding”. Здесь используется трехшаговый диалог при установлении соединения (SYN -> syn+ack -> ack; см. описание протокола TCP в разделе 4.4.3). Когда ЭВМ-1 получает запрос syn от ЭВМ-2, она должна подождать в частично открытом состоянии, по крайней мере, 75 секунд. Это позволяет успешно устанавливать связь даже в условиях очень больших сетевых задержек. Проблема заключается в том, что многие реализации способны отслеживать ограниченное число соединений (по умолчания 5). ЭВМ-злоумышленник может воспользоваться ограниченностью очереди и послать атакуемой ЭВМ большое число SYN-запросов, не отвечая на присылаемые SYN+ACK. В результате очередь будет быстро переполнена и прием запросов на соединение прекратится до тех пор, пока очередь не будет обслужена или очищена по таймауту. Данный метод пригоден для отключения ЭВМ от сети, во всяком случае, на 75 сек. Этот вид атаки часто является частью процедуры проникновения, когда нужно заблокировать ЭВМ от получения нежелательных откликов.
Существует разновидность атаки, когда хакер посылает данные в пакетах с адресом отправителя, отличным от его собственного (при этом трудно установить адрес, откуда такая атака предпринимается). Здесь имеются некоторые проблемы для атакующей стороны. ЭВМ-адресат посылает все отклики по указанному адресу отправителя, кроме того, хакеру нужно как-то выяснить порядковый номер сегмента, записываемый в каждый пересылаемый пакет. При установлении соединения оконечный сегмент, содержащий ACK, должен нести ISN (initial sequence number; cм. описание транспортного протокола TCP раздел 4.4.3) удаленной ЭВМ. Этот сегмент посылается ЭВМ, чей адрес указан в первоначальном запросе SYN. Хакер должен выяснить ISN каким-то иным способом (этому может помочь служба netstat). Так как ISN 32-разрядное число случайно угадать его совсем не просто. Но в большинстве систем (например, unix bsd) ISN берется из некоторого счетчика, содержимое которого увеличивается на 128 каждую секунду и на 64 после каждого нового соединения. Например:
x -> s: syn(ISNx)
s -> x: syn(ISNs), ack(ISNx) (получено искомое текущее значение кода ISNs)
Таким образом, установив однажды соединение с нужной ЭВМ (s), некоторое время спустя можно с высокой вероятностью угадать значение ISN, послав несколько пакетов с разными значениями ISN. При завершении процедуры посылается сегмент SYN+ACK, который будет отвергнут, так как машина получатель не инициализировала связь. В пакете отклике будет установлен флаг RST и соединение окажется абортированным. Чтобы этого не произошло, хакер может предпринять атаку типа syn-flooding, что приведет к игнорированию SYN+ACK. В результате соединение будет установлено и хакер, празднуя победу, может продолжить свое черное дело, например, он может исполнить какую-либо r-команду на атакуемой ЭВМ. Если даже изменять ISN каждые 4 микросекунды, проблему угадывания разрешить не удастся. Радикальным решением может стать лишь псевдослучайная генерация ISN-кодов (при этом случайным образом должны задаваться не менее 16 бит). Решить проблему поможет шифрование соответствующей части содержимого пакета. Рассмотрим здесь еще несколько таких атак.
Один из известных методов базируется на IP-опции “маршрутизации отправителя” (source routing). ЭВМ инициатор обмена может специфицировать маршрут, которым получатель должен воспользоваться при пересылке отклика. Маршрут может быть специфицирован так, чтобы он проходил через узел, контролируемый хакером. Эта, достаточно простая методика атаки, в настоящее время неэффективна, так как большинство маршрутизаторов сконфигурированы так, чтобы отфильтровывать пакеты с маршрутизацией отправителя.
Интересные возможности предоставляет вариант, когда хакер вставляет свою машину на пути обмена двух других узлов (hijacking). Обычные методы атак (типа spoofing) могут не привести к успеху из-за необходимости идентификации (пароль!). В данном методе хакер позволяет завершиться установлению связи и аутентификации и только после этого перехватывает контроль над виртуальным каналом. Этот способ использует механизм “десинхронизации” tcp-соединения. Когда порядковый номер полученного пакета не совпадает с ожидаемым значением, соединение называется десинхронизованным. Полученный пакет в зависимости от его номера будет выброшен или буферизован (если он находится в пределах окна). Таким образом, если узлы, участвующие в обмене сильно десинхронизованы, приходящие к ним пакеты будут отбрасываться. Хакер в этом случае может вводить пакеты с корректными порядковыми номерами. Разумеется, это совсем просто, если машина хакера является транзитной, что позволяет ей “портить” или удалять нормальные пакеты и подменять их своими. Атака же возможна и в случае, когда машина хакера находится где угодно. В этом случае “отброшенные” пакеты могут вызвать посылку ACK, которые содержат ожидаемое значение порядкового номера пакета, но и они будут отвергнуты из-за неверного их номера и т.д.. При реализации этой схемы пересылается большое число “лишних” пакетов ACK. Количество их будет сколь угодно велико, по этой причине данная ситуация называется “штормом ACK’. Обмен уведомлениями (ACK) о неверных ISN будет продолжаться до тех пор, пока один из таких пакетов не будет потерян. Механизм обмена IP-дейтограммами устроен так, что вероятность потери тем выше, чем больше пакетов передается, т.е. процесс саморегулируется. Тем не менее, высокая интенсивность потока сегментов ACK может говорить об атаке. В норме процент сегментов ACK от общего потока TCP составляет 30-45%. Иллюстрацией данного метода нападения может служить рис. 6.1.
Рис. 6.1
Десинхронизация может быть осуществлена при установлении соединения. Хакер в этом случае обрывает процесс трехшагового диалога. После того как ЭВМ Б пошлет SYN+ACK ЭВМ А, ЭВМ хакера пошлет пакет от Б к А, который с помощью бита RST оповещает о закрытии соединения. После этого затевается новый трехшаговый диалог с целью установления соединения с А, но уже с другими кодами порядковых номеров. Схема алгоритма атаки показана на рис. 6.2 (Сравните с рис. 4.4.3.3 и 4.4.3.4).
ЭВМ Б проигнорирует сообщения от А, так как они имеют неправильные (навязанные хакером) номера, а ЭВМ А проигнорирует сообщения от Б, так как ожидает, что они будут пронумерованы по-новому. Теперь хакер знает, какие номера нужны А и Б (непосредственно же А и Б взаимодействовать не могут, так как не знают правильных номеров) и может перехватывать, модифицировать или посылать сообщения по своему усмотрению как А, так и Б.
Но десинхронизация может быть реализована и в ходе сессии. Если послать флаг RST в середине сессии, соединение будет закрыто, о чем будет оповещено приложение и пользователь. Для того чтобы вызвать десинхронизацию в середине сессии, не закрывая соединения, достаточно поменять порядковые номера в сообщениях. Протокол telnet имеет механизм, который позволяет решить такую задачу. В рамках протокола можно посылать команды nop (“Ничего не делать”, согласитесь – хорошие команды!). Эти команды не производят никакого эффекта, но увеличивают ожидаемое значение порядкового номера сегмента. Послав некоторое количество таких команд, ЭВМ хакера вызовет десинхронизацию. Теперь только хакер знает правильные значения порядковых номеров пакетов и может начать свою подрывную работу.
Одним из наиболее эффективных методов обнаружения таких атак помимо процента сегментов ACK является сравнение потоков ACK для сервера и клиента. Полной гарантией безопасности в такой ситуации может стать только шифрование на прикладном уровне, например по схеме kerberos. В случае использования почты хороший результат может дать электронная подпись (например, PGP).
Атака на раннем этапе установления соединения может осуществляться следующим образом. Соединение при этом разрушается и вместо него формируется новое с другим значением ISN. Хакер прослушивает виртуальный канал и ждет сообщения SYN+ACK от сервера клиенту (вторая фаза установления соединения). При получении такого сообщения хакер посылает серверу RST-кадр, а затем SYN-пакет с теми же параметрами (TCP-порт), но с другим значением ISN (далее и на рис 6.2 этот кадр обозначается a_ack_0; префикс А указывает на принадлежность атакующей машине хакера). Сервер, получив RST, закроет прежнее соединение и, получив SYN, сформирует новое для того же порта, но с новым значением ISN. После чего пошлет клиенту кадр SYN+ACK. Детектировав это пакет хакер посылает серверу кадр ACK. При этом сервер переходит в состояние established. Клиент перешел в это состояние при получении от сервера первого кадра SYN+ACK. На рис. 6.2 не показан обмен пакетами ACK, вызванными получением некорректных значений ISN. Как сервер так и клиент находятся в несинхронизованном состоянии established. Обмен здесь полностью контролируется атакующей ЭВМ
Рис. 6.2. Алгоритм атаки с использованием десинхронизации. Префикс А указывает на то, что сегмент послан атакующей ЭВМ; С - клиентом; s - сервером. Отправка атакующих кадров выделена малиновым цветом.
Определенные услуги хакеру может оказать внутренний протокол маршрутизации rip. Этот протокол служит для рассылки информации о маршрутах в локальной сети и не требует контроля доступа, что всегда благоприятствует злоумышленникам. Хакер может разослать маршрутную информацию, которая убедит окружающие узлы в том, что наикратчайший путь во внешний мир проходит через ЭВМ хакера Х. Тогда все пакеты, адресованные за пределы локальной сети, будут сначала попадать в ЭВМ Х.
Протокол управляющих сообщений ICMP носит вспомогательный характер (вспомним популярную утилиту ping, использующую этот протокол). Пакеты ICMP также не требуют проверки доступа (именно благодаря этому протокол пригоден для работы в масштабах Интернет). По одной этой причине протокол привлекателен для хакеров. Известны случаи, когда с его помощью люди с разных континентов бесплатно обменивались сообщениями. Пригоден протокол и для блокировки обслуживания. Для блокировки обслуживания используются icmp-сообщения “time exceeded” (превышено время) или “destination unreachable” (адресат недоступен). Первое сообщение означает, что предел указанный в поле TTL заголовка пакета превышен. Такое может произойти из-за зацикливания пакетов или, когда адресат расположен очень далеко. Сообщение “destination unreachable” имеет несколько значений. Но все они означают, что нет способа благополучно доставить пакет адресату. Оба сообщения вынуждают адресата немедленно прервать соединение. Для реализации своих коварных планов хакеру достаточно послать одно из этих сообщений одному или обоим участникам обмена.
Протокол ICMP может использоваться и для перехвата пакетов. ICMP-сообщение “redirect” обычно используется внешними портами (gateway) сети в случаях, когда какая- то ЭВМ по ошибке полагает, что адресат находится вне локальной сети и направляет пакеты, адресованные ему, через внешний порт. Хакер может послать ICMP-сообщение “redirect” и вынудить другую ЭВМ посылать пакеты через узел, указанный хакером. У данного метода (также как и предыдущего с использованием RIP) имеется определенное ограничение – хакер и жертва должны находиться в пределах общей локальной сети.
Ещё одним объектом атак может стать DNS (domain name service) локальной сети. Например, администратор узла durak.dura.com может принять решение разрешить только местные соединения. Это может быть специфицировано с помощью записи “allow *.dura.com”, а не обязательно через указание IP-адресов. Тем более, что в сети может использоваться большое число блоков IP-адресов. Когда соединение установлено ЭВМ durak обращается к DNS для того, чтобы преобразовать IP-адрес отправителя в имя, которое затем служит для проверки условия, заданного администратором. Если хакер имеет доступ к местному DNS-серверу, он может заставить DNSоткликаться на его IP-адрес любым именем ЭВМ или домена. Зная об установленных администратором ограничениях, хакер может сделать так, что на запрос с его IP-адресом DNS будет откликаться именем “trustme.dura.com” (что удовлетворяет установленному ограничению). Такая атака может быть легко предотвращена путем повторного DNS-запроса с именем ЭВМ, присланным при первом запросе. Если IP-адрес, полученный при втором запросе, не совпадет с использованным в качестве параметра в первом, это означает, что DNS подверглась атаке.
Для атаки DNS извне достаточно узнать номер используемого UDP порта и ISN. О способах определения ISN говорилось выше. Задача упрощается в тех случаях, когда начальным значением ISN является нуль. Номер же используемого в данный момент UDP-порта при определенном везении можно найти путем подбора, ведь здесь нет никакой аутентификации или ограничений на число попыток. DNS один из самых привлекательных объектов для атак, так как через посредство AXFR-запросов можно получить информацию об узлах, которые используют определенные версии ОС с известными слабостями, упрощающими вторжение.
Точкой уязвимости могут быть загружаемые через сеть рабочие станции или Х-терминалы. Процедура загрузки предполагает использование протоколов RARP, TFTP и BOOTP. Все они практически не имеют сколько-нибудь серьезной защиты. Наиболее уязвим протокол RARP. Здесь желательно позаботиться о том, чтобы номер порта udp выбирался ЭВМ, осуществляющей загрузку случайным образом. В противном случае хакер может легко перехватит процедуру обмена и загрузить нужную ему конфигурацию программного обеспечения, обеспечив себе широкие ворота для проникновения. bootp предлагает дополнительные возможности защиты в виде 4-байтного случайного кода идентификатора процедуры (transaction ID). Это заметно мешает хакеру прервать процедуру и инициировать новую сессию загрузки (rebooting). Должны быть предприняты все меры, чтобы начатая процедура загрузки была своевременно завершена. Пребывание системы в промежуточном состоянии заметно облегчает разнообразные атаки.
Некоторые другие виды атак описаны в разделе, посвященном протоколу http. Многие из перечисленных выше проблем решаются при использовании прокси серверов типа firewall.
Но даже Firewall не может предотвратить атак со стороны хакеров, работающих внутри локальной сети. Здесь к их услугам огромный арсенал. Это, прежде всего, использование сетевого интерфейса для приема всех пакетов, следующих по сегменту (6-ой режим работы интерфейса), а также программные продукты типа tcpdump или Etherfind. Такой режим легко позволяет перехватывать незашифрованные пароли, определять используемые номера портов или ISN. К счастью такой комфорт для хакера предоставляется в пределах его логического сегмента, что стимулирует, кроме всего прочего, использование мостов, переключателей и локальных маршрутизаторов, которые ограничивают зону, где хакер может осуществлять перехваты. По этой же причине рекомендуется авторизованным администраторам работать с консоли, а не удаленного терминала. Следует иметь в виду, что обнаружить такого “шалуна” не так просто, ведь он может во многих случаях указывать в посылаемых пакетах не свой IP- и MAC-адрес.
Еще одним инструментом взлома может оказаться протокол ARP. Хакер может послать большое число широковещательных запросов, содержащих несуществующий IP-адрес. ЭВМ при получении такого запроса должна его обработать и может попытаться его переадресовать какому-то серверу. Всё это уже само по себе нежелательно, так как порождает большой паразитный трафик. Помимо этого хакер может попытаться послать широковещательный отклик, сообщая свой MAC-адрес в качестве адреса места назначения. Это может при определенных условиях предоставить возможность перехвата трафика между ЭВМ, пославшей первичный запрос, и истинным узлом назначения. Таким образом, постоянный мониторинг широковещательных запросов следует считать одной из составных частей системы безопасности локальной сети (см. также Robert T. Morris, A Weakness in the 4.2bsd Unix TCP/IP Software, Computer Science Technical Report N 117, at&t Bell laboratories), тем более что такой мониторинг не пораждает дополнительного трафика.
Определенную пользу с точки зрения безопасности может принести программы типа wrapper, которая позволяет отфильтровать нежелательные запросы и решить проблему аутентификации. Новые возможности в этой сфере предоставит новая версия протокола IPv6. Некоторые проблемы могут быть решены путем шифрования содержимого пакетов.
Применение сетей расширяется со скоростью 20% в месяц. Внешний трафик мультинациональных организаций увеличивается со скоростью 30% в год, а только за 1996 год сетевые воры украли ценной информации на сумму более 10 млн. долларов США (www.cuviello.com/_potrfolio/_semaphore).
Число зарегистрированных попыток нелегального проникновения в информационные системы растет экспоненциально, достигнув темпа прироста 60% в год. Но нужно принимать во внимание, что существенная часть таких попыток остается незамеченной или незарегистрированной. Адекватны этому и темпы роста расходов крупных фирм на средства и системы информационной безопасности.
Следует, впрочем иметь в виду, что чем лучше сеть (или ЭВМ) защищена от хакеров, тем менее удобно в ней работать. Поэтому администратор сети всегда должен выбирать меньшее из зол, нельзя же делать лечение более опасным, чем сама болезнь.
Хакер, пытающийся нелегально проникнуть в ЭВМ, обычно начинает с использования процедуры Finger, чтобы определить имена реальных пользователей сети или ЭВМ (имя одного пользователя обычно известно - это root). Администратор сети-жертвы может заблокировать работу Finger. Но именно этот протокол наряду с SMTP используется системами Whois, X.500 и FRED при поиске людей в сети Интернет. Заблокировав Finger, администратор усложняет общение с внешними сетями.
Есть все же правила, следовать которым должен любой администратор. Среди них жесткое требование к выбору паролей и регулярной их смене является наиважнейшим. Известно, что 80% всех проблем, связанных с нелегальным проникновением в сеть, вызваны плохими паролями.
Пароль должен содержать не менее 5-7 символов. Желательно, чтобы он включал в себя строчные и прописные символы, а также цифры. Любые имена, фамилии, общеизвестные географические названия, названия улиц, номер страхового полиса, кредитной карточки, домашний номер телефона (записанные обычным образом или задом на перед), последовательности клавишей типа qwerty или абвгд и т.д. совершенно непригодны в качестве паролей, так как их подбор, например, с помощью программы satan занимает не более 5 минут. Наиболее важные части системы могут быть защищены двойным паролем, но даже это не дает полной гарантии. Во-первых, имеется возможность перехвата ваших пакетов (например, с помощью программы tcpdump или ее аналога), когда вы вводите свой пароль с удаленного терминала. Во-вторых, существуют программы типа "троянского коня", которые, будучи засланы в многопользовательскую систему, перехватывают весь ввод с терминалов, записывают их в виртуальные файлы и спустя какое-то время пересылаются "хозяину коня". На этом арсенал орудий взлома не исчерпывается. Одним словом, если у вас имеется информация, доступ к которой не желателен, не храните ее в ЭВМ, подключенной к Интернет (или любой другой аналогичной сети). Следует иметь в виду, что "шалуны" могут быть и среди ваших коллег или друзей. Никогда ни при каких обстоятельствах не следует передавать свой пароль кому бы то ни было. Если это в вашей власти, помогите просящему получить к ЭВМ легальный доступ, но не передавайте пароль. В моей практике был случай, когда один программист из ИТЭФ передал свой пароль своему другу. Этот друг ради баловства через узел ИТЭФ заслал троянского коня в амстердамский телекоммуникационный узел. Факт засылки стал известен (для обнаружения используется программный пакет cops) и администратор сети прислал нам в институт оповещение об этом досадном инциденте. Были приняты административные меры к человеку, передавшему свой пароль (он был лишен определенных привилегий и доступа к ряду ЭВМ). Вряд ли какой-либо администратор мечтает о славе пособника сетевым террористам.
Безопасность сети определяется ее администратором. Именно он должен позаботиться о распределении ответственности между пользователями и администраторами ЭВМ и субсетей, именно он определяет конфигурацию программного обеспечения узла, вырабатывает меры на случай вторжения или повреждения системы. Администратор сети формулирует требования к сетевым паролям и контролирует их выполнение, определяет время жизни паролей (рекомендуемое время замены паролей равно 3-6 месяцам, новый пароль должен радикально отличаться от старого).
В тех случаях, когда ЭВМ помимо терминальных входов имеет доступ через модемы, используются, кроме того, так называемые “телефонные пароли” (dialup passwords). В этом случае во время процедуры logon помимо имени-идентификатора и пароля вводится также и телефонный пароль. Этот пароль является общим для всех пользователей на данной машине. Управляет этой процедурой исполняемый файл /etc/dpasswd. Программа имеет ряд опций. Сами пароли хранятся в закодированном виде в файле /etc/d_passwd. Если идентификация пользователя по названным выше трем параметром не увенчалась успехом, пользователю будет предложено повторить процедуру без указания того, какой из параметров введен неверно.
Для того чтобы контролировать, кто, когда и сколько времени провел в вашей ЭВМ, имеется файл-дневник (log-файл), где производятся соответствующие записи (например, /etc/wtmp). В таблице 6.1 размещены ссылки на различные log-файлы.
Таблица 6.1.
Каталог и имя файла |
Описание |
| /etc/bootplog | Предназначен для документирования выполнения операций загрузки bootp |
| /usr/adm/errlog | Регистратор ошибок на жестком диске |
| /usr/adm/messages | Имя информационного файла syslog |
| /usr/adm/sulog | Журнал записи входов в систему суперпользователя (root) |
| /usr/lib/cron/log | Журнал регистрации исполнения команд cron (кто, что, когда). Могут записываться и сообщения об ошибках. |
| /usr/spool/mqueue/syslog | Журнал записи операций sendmail и сообщений об ошибках. |
Схема с шифрованием проще реализовать для корпоративных сетей, т.е. для сетей принадлежащих одной фирме или отрасли (см. также раздел 6.5 и 6.6 ). Аналогичная схема может успешно использоваться между партнерами, которые заранее согласовали метод и ключи шифрования. Шифровка-дешифровка может проводиться аппаратным или программным образом для текстов или даже самих пересылаемых пакетов. Здесь предполагается наличие механизма пересылки ключей, подтверждения их получения и т.д. Шифрование не заменяет другие меры безопасности, так как несанкционированное вторжение может привести к потере или повреждению файлов, а в особо тяжелых случаях к разрушению всей операционной системы. В unix имеется две команды для шифрования - DES (data encryption standard) и crypt. Последняя команда базируется на старом методе кодирования, использованном в немецкой шифровальной машине enigma времен второй мировой войны. Обе программы имеют сходный формат применения и требуют ключ, который представляет собой последовательность символов, аналогичную паролю. Для указания ключа служит опция -k. Опция -e задает режим шифрования, -d - дешифрования. Так как программа crypt обеспечивает заметно меньшую защиту, чем DES, можно сначала архивировать файл, например, с помощью программы tar. На системах шифрования базируются некоторые почтовые системы, например, PGP (pretty good privacy) или PEM. Современные системы электронных подписей и конфиденциальной электронной почты основаны обычно на открытом и секретном ключах, эта технология (шифрование открытым ключом) базируется на криптографическом алгоритме Rivest-Shamir-Adelman’а (RSA). Эти ключи формируются попарно и являются математически связанными. Первый может пересылаться по обычным (открытым) каналам связи и используется для шифрования отправителем, а второй (секретный) - не пересылается и служит только для дешифрования получателем. Следует учитывать, что применение шифрования в России регулируется специальными законами.
Желательно, чтобы любые два объекта в сети общались друг с другом с использованием индивидуального набора ключей. Если в сети имеется n объектов, то необходимое число ключей равно [(n-1)*n]/2 (для n=100 это число равно 4950). Скрытое и эффективное хранение такого числа ключей само по себе уже может представлять проблему (а если n равно 1000!).
К сожалению, алгоритм RSA работает довольно медленно, по этой причине для шифрования больших объемов информации используются алгоритмы только с одним ключом (секретным), например, технология DES, которая способна гарантировать приемлемое быстродействие для шифрования и дешифрования в реальном масштабе времени. Секретный ключ DES пересылается с использованием техники шифрования RSA. RSA техника удобна для взаимной идентификации узлов до начала информационного обмена и для программ автоматического управления генерацией и распределением ключей дешифровки в сетях с большим числом объектов.
Существуют и аппаратные средства шифрования и контроля доступа, как отечественные, так и зарубежные (например, RG xxx комплекты фирмы racal или оборудование компании semaphore). Использование аппаратных средств может сохранить пропускную способность сети при введении шифрования/дешифрования неизменной. Особо эффективными для блокировки нелегального доступа могут быть специальные кодовые карточки, которые можно использовать и в случае удаленного доступа через коммутируемую телефонную сеть.
Интернет - открытая система, поэтому любые системы защиты плохо сочетаются с идеологией этой сети. Но Интернет может реально обеспечить любой уровень защиты уже сегодня. Рассмотрим одну из наиболее распространенных схем защиты (рис. 6.3).
Рис. 6.3.
Сначала формируется традиционный TCP-канал (для Telnet, FTP или SMTP). Этот канал используется для обмена командами. Далее управление передается блоку безопасности, который формирует отдельный канал для обмена шифрованной информацией (например, Kerberos). Перед началом обмена блок выясняет наличие аналогичного блока у партнера. Практически такая схема может быть реализована с использованием алгоритма Нидхама-Шрёдера (Needham-Schroeder). Здесь каждая ЭВМ использует общий ключ с сервером аутентификации. При необходимости установить соединение ЭВМ получает ключ от сервера и пересылает его адресату соединения (возможно в зашифрованном виде). Схема может работать с секретными и общедоступными ключами. Атака здесь затруднена не только из-за применения шифрования но и благодаря наличию дополнительного агента, участвующего в процессе соединения (сервера аутентификации). Функции такого сервера может взять на себя DNS. Конечно, не следует исключать возможности атаки на сервер аутентификации (например, с помощью подбора ISN).
Многие процедуры в Интернет не требуют для своего выполнения пароля, именно это обстоятельство создает еще одно окно уязвимости для сетей. Но и в случаях аутентификации с использованием пароля проблемы остаются. Если пароль передается в незашифрованном виде, он может быть легко перехвачен. Определенный интерес здесь может представлять и применение системы одноразовых паролей (например, skey). Суть этой технологии заключается в том, что после конфигурирования системы для очередной процедуры идентификации клиентом и сервером генерируется новый пароль. Перехват самого пароля в этом случае теряет смысл, так как воспользоваться им уже не возможно, а восстановить алгоритм формирования паролей даже по результатам достаточно большого числа перехватов практически не реально. Некоторые сетевые запросы (например, в HTTP) могут нести в себе пароли. Помимо перехвата таких сообщений имеется возможность использования их для подбора пароля, так как здесь часто нет ограничений на число попыток. Распознавание “свой-чужой” можно организовать непосредственно на пакетном уровне. Такая возможность предусмотрена в протоколе SNMP (поле community). Но возможно создание специального программного обеспечения, где все без исключения пакеты будут идентифицироваться. Для этого предусмотрены специальные коды для поля тип протокола (сети Ethernet). Например, для передачи шифрованных пакетов: UDP IP - 11; TCP/IP - 06; DEC LAT - 6004 и XNS - 0600. В последнее время широкое распространение получают индивидуальные сертификаты пользователя (см., например, www.verisign.com). Такие сертификаты эквивалентны высоконадежной электронной подписи идентифицирующей отправителя сообщения.
Создавая сеть, следует сразу закладывать некоторые элементы, обеспечивающие безопасность. Так прокладку сетевых кабелей желательно производить в металлических коробах, что сделает подключение к ним более затруднительным, или, там где это целесообразно, использовать оптоволоконные кабели. Повторители и концентраторы нужно размещать в запираемых шкафах. Некоторые концентраторы контролируют MAC-адреса пакетов. Такое оборудование позволяет блокировать порт, если обнаруживаются пакеты с неизвестным MAC-адресом, а также выявлять случаи подключения одного и того же MAC-адреса к разным портам. Определенную угрозу сетевой безопасности может представлять возможность присвоения хакером “чужого” MAC-адреса своей сетевой карте. Современные концентраторы запрещают подключенному к порту узлу передавать кадры с MAC-адресом, не совпадающим с определенным администратором для данного порта. Это обеспечивает дополнительную надежность канального уровня.
Как же можно определить, подверглась ли ваша ЭВМ атаке или нет? (Последующие рекомендации относятся к ОС UNIX).
Начинать надо с просмотра log-файла (см. ниже описание утилиты last). Но следует иметь в виду, что отсутствие подозрительных записей в этом файле не является гарантией безопасности. Хакер может без труда отредактировать этот файл.
Следующим шагом должен стать поиск любых спрятанных файлов. При этом нужно позаботиться о наличии копии всех рабочих системных и пользовательских файлов. Хакер может оставить каталоги с необычными именами типа “…”, “… “ (три точки + три пробела), “.xxx”, “.mail”, которые неопытный пользователь может принять за системные. Целесообразно контролировать неизменность базовых системных файлов, таких как logon, telnet и др., так как хакер, видоизменив их, может предоставить себе свободный доступ в систему. Полезно контролировать дату действующей версии таких программ. Далее следует просмотреть файл /etc/inetd.conf на предмет внесения в него каких-либо модификаций. Не рекомендуется разрешать в этом файле услуги типа: systat – порт 11; tftp – порт 69 и link – порт 87. Прежде всего следует искать строки, которые могут исполнять программы ядра (например, /bin/sh или bin/csh). Нужно проверить также все программы, на которые имеются ссылки в файле /etc/inetd.conf, так как хакер может заменить их и встроить в них программы типа троянского коня. Надо внимательно изучить содержимое файла /etc/hosts.equiv, /etc/hosts.lpd (эти файлы не должны допускать запись кому угодно) на наличие в них нелокальных имен ЭВМ, а также все файлы ~/.rhost в особенности ~root, ~uucp, ~ftp и другие программы, допускающие запись извне.
В случае обнаружения несанкционированного вторжения следует исследовать и другие ЭВМ, подключенные к сети. Нужно просмотреть файл /etc/passwd и выявить изменения, внесенные в него за последнее время. Особое внимание должно быть уделено авторизации новых пользователей.
Если ваша машина использует услуги UUCP, проверьте файл L.cmds. Он должен содержать только те команды, которые вам действительно нужны. Этот файл должен принадлежать root (а не uucp). Не следует оставлять без внимание содержимое файлов /etc/ttytab, /etc/ttys, а также /users/lib/aliases и любые другие файлы, определяющие конфигурацию системы. Везде, где возможно, нужно установить соответствующий уровень доступа к каталогам.
Определенного успеха в деле повышения защиты сети можно добиться, используя ограничения допуска. Маршрутизаторы и ЭВМ, имеющие контроль доступа, сверяют адрес отправителя запроса со списком доступа. Если адрес содержится в разрешительном списке, доступ реализуется, в противном случае запрос отвергается. Такие возможности предусмотрены в маршрутизаторах фирмы CISCO, имеются они и в некоторых сетевых пакетах UNIX (например, пакет wrapper). Этот пакет осуществляет мониторинг всех интернетовских и обычных сетевых запросов. Программа wrapper доступна по адресу: FTP:cert.sei.cmu.edu/pub/network_tools/tcp_wrapper.shar. Файл содержит исходный текст на языке Си и Makefile для генерации демона wrapper, который имеет имя tcpd.
В указанном выше депозитарии в каталоге info можно найти документ DOD 5200.28-std “Trusted Computer System Evaluation Criteria”, представляющий собой стандарт, который регламентирует общие принципы сетевой безопасности.
Целесообразно мониторировать доступ к fingerd, ftpd, tftpd, rshd, rlogind, rexecd и telnetd. Если вы строите защищенную систему, следует использовать статические таблицы маршрутизации. Должна быть заблокирована возможность добавления маршрутов по умолчанию в процессе загрузки системы. Регулярно просматривайте маршрутные таблицы с помощью команды netstat -nr.
При выборе программного обеспечения для защищаемой сети следует тщательно изучить его особенности, ведь авторы программ могут оставить "люки" (недокументированные обходы системы защиты) или предусмотреть универсальный ключ дешифровки сообщений. Абсолютных систем защиты не существует и вряд ли такие системы появятся в будущем. Но можно создать защиту, стоимость взлома которой не окупится. Именно к этому и следует стремиться (люди любопытны, но достаточно ленивы).
Помимо Finger, хорошую службу хакеру может сослужить программа TFTP (ведь она не требует пароля), если с помощью ее доступен файл /etc/passwd, где в закодированном виде хранятся все пароли. Заполучив этот файл, хакер сможет заняться подбором паролей на своей ЭВМ, благо для этой цели имеется немало программ. Желательно вообще закрыть доступ пользователей к TFTP, закомментировав, например, соответствующую запись в файле inetd.conf. Полезно также удалить systat и link. В новейших версиях ОС пароли хранятся в “теневых” файлах, недоступных для обычных пользователей.
Для проверки добротности паролей администратор сети может воспользоваться программами npasswd, passwd+ или SATAN. Программа npasswd проверяет соответствие паролей определенным требованиям перед их запоминанием в соответствующем файле. Среди параметров, контролируемых npasswd, содержится минимальное число символов в пароле, список нелегальных кодов (например, последовательности повторяющихся символов типа “wwww”). Программа контролирует отсутствие в пароле персональной информации, доступной с помощью Finger, проверяет наличие в пароле цифр и букв верхнего и нижнего регистров, а также общеупотребительных слов из словаря. Программа доступна по адресу: FTP://ftp.cc.utexas.edu/pub/npasswd.tar.Z. (см. также [14-16] в конце этой главы).
Программа passwd+ выполняет аналогичные функции, но предоставляет более гибкий набор средств тестирования паролей. passwd+ имеет специальный язык, позволяющий реконфигурировать систему контроля паролей. Конфигурация записывается в файл /etc/password.test (UNIX).
Программа SATAN (работает с ОС UNIX, в настоящее время доступна версия 1.1.1) была создана для подбора (“вскрытия”) паролей, но в умелых руках она может стать эффективным средством выбора надежных паролей и выявления непригодных. При использовании системы SATAN или других аналогичных программных продуктов нужно проявлять особую осторожность. Такие системы имеют встроенную систему защиты, но перехват, например, ключа сессии, может открыть доступ хакеру ко многим паролям пользователей. Эти программы для запуска требуют, как правило, системных привилегий.
Защищенность сети зависит от конфигурации программного обеспечения. Для ОС UNIX определенную угрозу предоставляют так называемые r-команды. Эти команды используют файлы /etc/hosts.equiv и .hosts. Следует проверить эти файлы и /etc/hosts.ltd на наличие символа (+). Нужно помнить, что файл .hosts имеется в каталоге каждого пользователя. Если в вашей сети используется UUCP, удалите все неиспользуемые команды из файла L.cmds, выполните команды chown root L.cmds, chown uucp L.sys и chmod 600 L.sys. Эти меры сделают вашу систему более устойчивой против нежелательных вторжений. Корректная конфигурация NFS и sendmail сделает систему еще безопаснее. Дальнейшей безопасности будет способствовать сокращение списка системных (secure) терминалов (файлы /etc/ttys и /etc/ttytab).
Но само по себе этого недостаточно - администраторы должны постоянно контролировать ситуацию. Для этого рекомендуется регулярно выполнять команды who и ps, которые сообщают список активных пользователей и процессов. Команды ps -aux для BSD и ps -ef для System 5 выведут на экран список пользователей, которые инициировали активные процессы. Вы можете также воспользоваться командой ls -lR, чтобы просмотреть принадлежность и уровни доступности файлов в каталоге. Хакеры часто оставляют на диске файлы, чтобы облегчить себе в будущем доступ или обеспечить системные привилегии. Для контроля ситуации следует время от времени выполнять команду ls -a | grep ‘^\.’, которая ищет файлы, начинающиеся с символа точка. Хакеры часто полагают, что пользователь воспримет файлы типа .mail или .xxxx как системные, и не будет беспокоиться. Если вами найдены файлы, вызывающие подозрения, следует немедленно проконсультироваться с администратором сети.
Объектом самого пристального внимания должны быть файлы /etc/inetd.conf, /etc/hosts.equiv, /etc/hosts.ltd, /etc/passwd и .rhosts. Доступ к ним должен быть ограничен, их копии полезно хранить в недоступном месте. Полезно также записать в отдельный файл основные параметры ваших рабочих файлов, это позволит вам заметить факт их модификации. Чтобы обнаружить “сюрпризы”, оставленные непрошеными визитерами, можно воспользоваться командой find / -user root -perm -4000 -print, которая ищет файлы, принадлежащие root и устанавливающие уровень привилегий -4000. Команда Find может использоваться для проверки уровня доступа к жизненно важным файлам (-perm -2 или -perm -2000), a также файлов без определенного хозяина (-nouser -o -nogroup). Последние файлы должны быть удалены.
Странная активность в системе в необычное время суток, в необычные дни или с неизвестного удаленного терминала должна вызывать пристальное внимание. Для контроля активности в ЭВМ (UNIX) служит команда last. Эта команда отображает содержимое файла /usr/adm/wtmp, где содержится информация о том кто, когда и откуда заходил в систему. Ниже приведен небольшой фрагмент результата работы команды last.
| Имя пользователя | Терминал | Имя домена | Дата входа | Время входа |
| ftp | ftp | svalla.smart.net | Sat Mar 30 | 02:57 |
| semenov | ttyp3 | flta.Helsinki.FI | Fri Mar 29 | 11:51 |
| ftp | ftp | osilab.nstu.nsk. | Fri Mar 29 | 08:21 |
| ftp | ftp | fsite.dialup.ru | Thu Mar 28 | 16:11 |
| ftp | ftp | ix-cha-nc9-55.ix | Thu Mar 28 | 04:59 |
| ftp | ftp | pmax.dymaxion.ns | Thu Mar 28 | 03:24 |
| ftp | ftp | slip-tsr.srcc.ms | Tue Mar 26 | 6:11 |
| FTP | FTP | pmax.dymaxion.ns | Sun Mar 24 | 05:34 |
| bobyshev | ttyp2 | 131.169.1.233 | Mon Nov 27 | 09: 57 |
| FTP | FTP | ftp01.blue.aol.c | Mon Nov 27 | 03:20 |
| FTP | FTP | foley.ripco.com | Mon Nov 27 | 01:03 |
/p> Записи располагаются от настоящего к прошлому, что видно из предлагаемого отрывка. В колонке <Имя пользователя> и <терминал> в случае “анонимного FTP” помещается метка FTP. Так как обычно результат работы команды last занимает десятки страниц, бывает полезно воспользоваться командой grep, чтобы просмотреть отдельные фрагменты файла /usr/adm/wtmp, отвечающие определенным критериям. Например:
last | grep '03:'
(поиск входов в систему межу 3 и 4 часами утра)
| FTP | FTP | pmax.dymaxion.ns | Thu Mar 28 | 03:24 |
| FTP | FTP | jwilson.ott.hook | Thu Mar 14 | 03:31 |
| FTP | FTP | assign29.utw.com | Sun Feb 25 | 03:40 |
| FTP | FTP | fh_ppp32.monmout | Thu Jan 25 | 03:07 |
| FTP | FTP | tpafl3-6.gate.ne | Wed Jan 24 | 03:52 |
| FTP | FTP | ttyC1.pandemoniu | Sat Dec 30 | 03:07 |
| FTP | FTP | student.uq.edu.a | Sat Dec 9 | 03:17 |
| FTP | FTP | s189_81.resnet.u | Wed Dec 6 | 03:37 |
| FTP | FTP | golden.ripco.com | Wed Nov 29 | 03:25 |
| FTP | FTP | hobbes.jct.ac.il | Wed Nov 1 | 03:43 |
Пользователю не важно, по какой причине он не получил своевременно важное сообщение, или почему реакция сети вдруг стала равной нескольким секундам. А такие вещи могут происходить из-за установки неоптимальных параметров сети (TTL, MTU, window и т.д.), в результате перегрузки сетевого сегмента (что может произойти, если один из пользователей разорвет кабельный сегмент) или из-за потока широковещательных запросов. Дестабилизация сети может происходить по причине зацикливания пакетов или осцилляций маршрутов. Зацикливание пакета возможно при установке маршрутов по умолчанию типа A -> B и B -> A, когда в системе появляется пакет с ошибочным адресом. Возможно это и при установке параметра вариация > 1 во внутреннем протоколе маршрутизации IGRP. Осцилляции маршрутов свойственны системам с динамическими протоколами маршрутизации при неверной установке таймеров. Источником потока широковещательных запросов может стать IP-мост, по обе стороны которого появились идентичные IP-адреса, или неисправное оборудование (например, сетевой принтер). Администратор должен отслеживать ситуацию и при возникновении нештатного ее состояния, с помощью диагностической программы выявить и устранить причину.
Вы можете быть защищены системой Firewall, использовать шифрование при обменах и т.д., но, если ваш персональный компьютер время от времени доступен для посторонних – он совершенно не защищен. Злоумышленник, вооруженный бутабильной дискетой, может стартовать ЭВМ и, обойдя, таким образом, необходимость ввести пароль, скопирует или сотрет нужные ему файлы. Несколько улучшит ситуацию конфигурация, которая требует ввода пароля на фазе загрузки системы (SYSKEY; Microsoft), а также запирание корпуса ЭВМ и порта флоппи-диска (если это предусмотрено). Если у злоумышленника достаточно времени, он может просто снять с вашей машины жесткий диск, поставить его на свою машину, и сделать все, что ему нужно. Так что какой-то гарантией безопасности может служить лишь надежный запор на помещении, где находится ваша ЭВМ.
Для мониторирования безопасности ЭВМ создан специальный набор программ COPS (Computer Oracle Password and Security). COPS контролирует доступ к файлам, каталогам и оборудованию, содержимое файлов /etc/passwd, /etc/group, /etc/hosts.equiv и .hosts, а также регистрирует изменения состояния SUID. После завершения всех проверок результат посылается в виде почтового сообщения системному администратору. Программы COPS доступны по адресу:
cert.sei.cmu.edu/pub/cops.tar.Z
Существует несколько подписных листов и депозитариев, аккумулирующих и распространяющих информацию по сетевой безопасности:
CERT (Computer Emergency Response Team) cert@cert.sei.cmu.edu. Депозитарий статей по данной тематике расположен по адресу:
FTP://cert.cei.cms.edu /pub/cert_advisories.
cert-advisory-request@cert.org
DDN Security Bulletins nic@nic.ddn.mil. Адрес FTP-сервера: nic.ddn.mil /scc/.
Risks Forum risks-request@csl.src.com.
Безопасность в UNIX. bugtraq-request@fc.net (сообщение в теле e-mail: subscribe bugtraq). Там же имеется архив: http://www.geek-girl.com/bugtraq/archieves.html.
То же для LINUX: linux-alert-request@RedHat.com (в поле subject: subscribe). Там же есть архив: http://www.redhat.com/linux-info/security/linux-alert/
Безопасность Windows NT listserv@rc.on.ca ( для подписка следует послать сообщение “SUB NTBUGTRAQ ваше имя” (имя, а не ваш почтовый адрес!). Там же имеется депозитарий http://ntbugtraq.rc.on.ca/archieves/ntbugtraq.html
VIRUS-L (информация о компьютерных вирусах на PC) listserv%lehiibm1.bitnet @mitvma.mit.edu. В теле сообщения следует поместить:
SUB VIRUS-L <ваше полное имя>.
Немало полезной информации по проблематике сетевой безопасности можно найти в группе новостей comp.security.announce и в анонимных депозитариях:
nic.merit.edu, pyrite.rutgers.edu, sparkyfs.erg.sri.com, ftp.win.tue.nl, info.cert.org, ftp.ucar.edu, ftp.ee.lbl.gov и т.д. (последние два адреса относятся к диагностическим сетевым программам).
Антивирусные программы можно найти во многих анонимных депозитариях, там же обычно есть разделы и по сетевой безопасности, например, www.ynet.com, http://www.esat.kuleuven.ac.be (система SESAME) или ftp://ftp.compapp.dcu.ie/pub/sesame и т.д. В таблице 6.2 приведены ссылки на серверы, посвященные проблематике безопасности и смежным областям.
Таблица 6.2. URL серверов по проблематике безопасности
/p> Библиография по проблематике сетевой безопасности
| 1 | RFC-1108 | U.S. Department of Defense Security Options for the Internet Protocol, S. Kent, 1991 |
| 2 | RFC-1244 | Site Security Handbook, P.Holbrook, J.Reynolds, 1991. |
| 3 | RFC-1281 | Guidelines for the Secure Operations of the Internet, R.Pethia, S.Crocket and B.Frazer, 1991. |
| 4 | RFC-1507 | DASS - Distributed Authentication Security Service, C. Kaufman, 1993 |
| 5 | RFC-1508 | Generic Security Service Application Program Interface, J. Linn, 1993 |
| 6 | RFC-1510 | The Kerberos Network Authentication Service (V5), J. Kohl, B. Numan, 1993 |
| 7 | RFC-1535 | A Security Problem and Proposed Correction With Widely Deployed DNS Software, E. Gavron, 1993 |
| 8 | RFC-1675 | Security Concerns for IPng, S. Bellovin, 1994 |
| 9 | RFC-1750 | Randomness Recommendations for Security, D. Eastlake, S. Crocker, J. Schiller, 1994 |
| 10 | RFC-1824 | The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange, (E.I.S.S.-Report 1995/4), H. Danisch, 1995 |
| 11 | RFC-1825 | Security Architecture for the Internet Protocol, R. Atkinson, 1995 |
| 12 | RFC-1827 | IP Encapsulating Security Payload (ESP), R. Atkinson, 1995 |
| 13 | RFC-1847 | Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, J. Galvin, S. Crocker, N. Freed, 199 |
| 14 | RFC-1858 | Security Considerations for IP Fragment Filtering, G. Ziemba, D. Reed, P. Traina, 1995 |
| 15 | TCP/IP Network Administration, Craig Hunt, O’Reilly & Associates, Inc., 1993 | |
| 16 | Practical UNIX Security, Simpson Garfinkel and Gene Spafford, O’Reilly & Associates, 1991 | |
| 17 | Computer Security Basics, Deborah Russell and G.T.Gangemi, O’Reilly & Assocates, 1991 | |
| 18 | RFC-1579 | Firewall-Friendly FTP, S. Bellovin, AT&T Bell Laboratories, February 1994 |
Сетевая диагностика с применением протокола SNMP
5.1 Сетевая диагностика с применением протокола SNMP
Семенов Ю.А. (ГНЦ ИТЭФ)
Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901, 1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042; std16, std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на рис. 4.1.1.
Рис. 4.1.1. Пример диагностируемой сети
Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ. Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены.
Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны.
Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками. В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig (venera.isi.edu/pub), hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch (windom.ucar.edu), snmpman (http:// www.smart.is/pub/mirror-indstate/snmp), netguard (oslo-nntp,eunet.no/pub/msdos/winsock/apps), ws_watch (bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.
Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community; формат пакетов описан, например, в книге Семенова Ю.А. “Протоколы и ресурсы Интернет”, Москва, “Радио и связь”, 1996). Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.
При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):
interface.iftable.ifentry.ifinucastpkts
interface.iftable.ifentry.ifinnucastpkts
interface.iftable.ifentry.ifinerrors
interface.iftable.ifentry.ifoutucastpkts
interface.iftable.ifentry.ifinnucastpkts
interface.iftable.ifentry.ifinunknownprotos
ip.ipinreceives
ip.ipinhdrerrors
ip.ipinaddrerrors
ip.ipinunknownprotos
ip.ipreasmreqds
ip.ipindelivers
icmp.icmpinmsgs
udp.udpindatagrams
udp.udpoutdatagrams
udp.udpnoports
udp.udpinerrors
tcp.tcpinsegs
tcp.tcpoutsegs
tcp.tcpretranssegs
tcp.tcpoutrsts
tcp.tcpinerror
Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так переменная snmpinbadcommunityuses {snmp 5} может сообщить о попытках несанкционированного доступа к базе mib. Переменные snmpintoobigs {snmp 8}, snmpingenerrs {snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д. полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, если ipfragfails велико, о неверном выборе MTU.
Рассмотрим средние значения некоторых переменных за сутки. Так переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормально. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети, если соотнести эти цифры с входным и выходным потоками пакетов можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результат работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки случилось мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках tcp-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети, чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.
Рис. 4.1.2.
Вариации tcpinsegs и udpindatagrams в течение недели
Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели. На рис. 4.1.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На рис. 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last (или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программой last на ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.
| ms977 | pts/0 | vitep5.itep.ru | tue sep 10 23:49 - 00:16 (00:27) |
| ms977 | pts/2 | vitep5.itep.ru | tue sep 10 22:20 - 23:46 (01:26) |
| ostrouh | pts/0 | athene.itep.ru | tue sep 10 18:30 - 18:43 (00:13) |
| titovich | pts/0 | athene.itep.ru | tue sep 10 18:30 - 18:30 (00:00) |
| vita | pts/3 | athene.itep.ru | tue sep 10 14:55 - 15:56 (01:00) |
| checho | pts/12 | itep05.itep.ru | tue sep 10 13:35 - 13:37 (00:01) |
| fomin | pts/10 | hydra.ifh.de | tue sep 10 13:16 - 13:22 (00:06) |
| checho | pts/7 | itep05.itep.ru | tue sep 10 13:09 13:16 (00:07) |
| illarion | pts/7 | xt07.itep.ru | tue sep 10 12:45 12:45 (00:00) |
| vita | pts/9 | athene.itep.ru | tue sep 10 11:55 13:03 (01:07) |
| bely | pts/12 | pcx01.itep.ru | tue sep 10 11:49 12:02 (00:13) |
| vita | pts/13 | athene.itep.ru | tue sep 10 11:49 11:52 (00:03) |
| efre | pts/4 | pcx10.itep.ru | tue sep 10 10:05 10:24 (00:18) |
| checho | pts/0 | 169-151-147.ipt. | tue sep 10 05:07 05:09 (00:01) |
| ssemen | ftp | clotho.itep.ru | mon sep 09 20:14 20:15 (00:01) |
| ssemen | ftp | clotho.itep.ru | mon sep 09 19:34 19:35 (00:00) |
| ostrouh | pts/3 | athene.itep.ru | mon sep 09 19:20 19:40 (00:20) |
| ozero | pts/0 | athene.itep.ru | mon sep 09 19:13 22:44 (03:30) |
| ozero | pts/5 | itep05.itep.ru | mon sep 09 18:05 18:32 (00:27) |
| olyalin | pts/6 | itep05.itep.ru | mon sep 09 16:19 16:27 (00:08) |
| efre | ftp | pcx10.itep.ru | mon sep 09 16:14 16:15 (00:00) |
| mara | pts/1 | hpl3pur2.cern.ch | mon sep 09 16:02 16:27 (00:24) |
| mara | pts/1 | hpl3pur2.cern.ch | mon sep 09 15:50 15:54 (00:04) |
| itep977 | pts/2 | 1mars.itep.ru | mon sep 09 15:22 15:23 (00:00) |
| ozero | pts/20 | aix0.itep.ru | mon sep 09 15:06 15:36 (00:29) |
| ozero | pts/12 | itep05.itep.ru | mon sep 09 14:56 14:56 (00:00) |
| galy | pts/16 | athene.itep.ru | mon sep 09 14:27 14:31 (00:03) |
| bely | pts/15 | vitep5.itep.ru | mon sep 09 14:09 10:36 (20:27) |
| sed | pts/5 | pcx11.itep.ru | mon sep 09 14:01 14:01 (00:00) |
| kisel | pts/1 | vxitep.itep.ru | mon sep 09 13:59 15:22 (01:22) |
| ozero | pts/12 | itep05.itep.ru | mon sep 09 13:53 14:55 (01:02) |
| ozero | pts/2 | 193.148.166.214 | mon sep 09 13:40 13:41 (00:00) |
| ozero | pts/8 | 193.148.166.214 | mon sep 09 13:32 13:37 (00:04) |
| vita | pts/9 | aix0.itep.ru | mon sep 09 13:32 13:32 (00:00) |
| vita | pts/2 | vitep5.itep.ru | mon sep 09 13:32 13:32 (00:00) |
| checho | pts/3 | itep05.itep.ru | mon sep 09 13:11 13:12 (00:00) |
| efre | pts/3 | pcx10.itep.ru | mon sep 09 12:12 12:23 (00:10) |
| kisel | pts/2 | vxitep.itep.ru | mon sep 09 12:11 12:43 (00:32) |
| checho | pts/6 | itep05.itep.ru | mon sep 09 12:02 12:03 (00:00) |
| kisel | ftp | pcx11.itep.ru | mon sep 09 11:42 11:43 (00:00) |
| kisel | ftp | ion04.cern.ch | mon sep 09 10:59 11:06 (00:06) |
| galy | pts/1 | athene.itep.ru | mon sep 09 10:57 10:58 (00:00) |
| titovich | pts/4 | athene.itep.ru | mon sep 09 10:20 10:21 (00:01) |
| korol | pts/0 | 193.124.225.174 | mon sep 09 05:20 05:57 (00:37) |
/p> Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и рис. 5.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.
Рис. 5.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts
По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На рис. 5.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 5.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos.
На рис. 5.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на рис. 5.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).
Рис. 5.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)
Рис. 5.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.
Рис. 5.1.6(а, б). Суточные вариации потоков TCP-сегментов
Сетевое моделирование
4.5.17 Сетевое моделирование
Семенов Ю.А. (ГНЦ ИТЭФ)
Предельные пропускные способности различных фрагментов сети и зависимости потерь пакетов от загрузки отдельных станций и внешних каналов.
Время отклика основных серверов в самых разных режимах, в том числе таких, которые в реальной сети крайне нежелательны.
Влияние установки новых серверов на перераспределение информационных потоков (Proxy, Firewall и т.д.).
Решение оптимизации топологии при возникновении узких мест в сети (размещение серверов, DNS, внешних шлюзов, организация опорных каналов и пр.).
Выбор того или иного типа сетевого оборудования (например, 10BaseTX или 100BaseFX) или режима его работы (например, cut-through, store-and-forward для мостов и переключателей и т.д.).
Выбор внутреннего протокола маршрутизации и его параметров (например, метрики).
Определение предельно допустимого числа пользователей того или иного сервера.
Оценка необходимой полосы пропускания внешнего канала для обеспечения требуемого уровня QOS.
Оценка влияния мультимедийного трафика на работу локальной сети, например, при подготовке видеоконференций.
Перечисленные задачи предъявляют различные требования к программам. В одних случаях достаточно провести моделирование на физическом (MAC) уровне, в других нужен уже уровень транспортных протоколов (например, UDP и TCP), а для наиболее сложных задач нужно воспроизвести поведение прикладных программ. Все это должно учитываться при выборе или разработке моделирующей программы. Ведь нужно учесть, что ваша машина должна в той или иной мере воспроизвести действия всех машин в моделируемой сети. Таким образом, машина эта должна быть достаточно быстродействующей и, несмотря на это, моделирование одной секунды работы сети может занять при определенных условиях не один час.
Результаты моделирования должны иметь точность 10-20%, так как этого достаточно для большинства целей и не требует слишком много машинного времени. Следует иметь в виду, что для моделирования поведение реальной сети, надо знать все ее рабочие параметры: длины кабеля от концентратора до конкретной ЭВМ, задержки используемых кабелей, задержки концентраторов (этот параметр часто отсутствует в документации и его придется брать из документации на сетевой протокол, например из IEEE 802.3). Параметры могут быть определены и прямым измерением. Чем точнее вы воспроизводите поведение сети, тем больше машинного времени это потребует. Кроме того, вам предстоит сделать некоторые предположения относительно распределения загрузки для конкретных ЭВМ и других сетевых элементов, задержек в переключателях, мостах, времени обработки запросов в серверах. Здесь нужно учитывать и характер решаемых на ЭВМ задач. www/ftp-сервер или обычная персональная рабочая станция создают различные сетевые трафики. Определенное влияние на результат могут оказывать и используемые ОС. В случае моделирования реальной сети можно произвести соответствующие измерения, что иногда тоже не слишком просто. Учитывая сложность моделирования на одной ординарной ЭВМ, следует ограничиваться моделированием не более чем одной минуты для каждого из наборов параметров (этого времени достаточно для копирования практически любого файла через локальную сеть). Исключение может составлять моделирование внешнего трафика, но в этом случае весь локальный трафик должен рассматриваться как фоновый.
4.5.17.1 Аналитическое моделирование
Определение характеристик сети до того, как она будет введена в эксплуатацию, имеет первостепенное значение. Это позволяет отрегулировать характеристики локальной сети на стадии проектирования. Решение этой проблемы возможно путем аналитического или статистического моделирования.
Аналитическая модель сети представляет собой совокупность математических соотношений, связывающих между собой входные и выходные характеристики сети. При выводе таких соотношений приходится пренебрегать какими-то малосущественными деталями или обстоятельствами.
Телекоммуникационная сеть при некотором упрощении может быть представлена в виде совокупности процессоров (узлов), соединенных каналами связи. Сообщение, пришедшее в узел, ждет некоторое время до того, как оно будет обработано. При этом может образоваться очередь таких сообщений, ожидающих обработки. Время передачи или полное время задержки сообщения d равно:
D = Tp + S + W,
где Tp, S и W, соответственно, время распространения, время обслуживания и время ожидания. Одной из задач аналитического моделирование является определение среднего значения D. При больших загрузках основной вклад дает ожидание обслуживания W. Для описания очередей в дальнейшем будет использована нотация Д. Дж. Кенделла: A/B/C/K/m/z,
где А – процесс прибытия: В – процесс обслуживания; С – число серверов (узлов); К – максимальный размер очереди (по умолчанию -
); z – схема работы буфера (по умолчанию FIFO). Буквы А и В представляют процессы прихода и обслуживания и обычно заменяются следующими буквами, характеризующими закон, соответствующий распределения событий.D – постоянная вероятность;
M – марковское экспоненциальное распределение;
G – обобщенный закон распределения;
Ek – распределение Эрланга порядка k;
Hk – гиперэкспоненциальное распределение порядка k;
Наиболее распространенными схемами работы буферов являются FIFO (First-In-First-Out), LIFO (Last-In-First-Out) и FIRO (First-In-Random-Out). Например, запись M/M/2 означает очередь, для которой времена прихода и обслуживания имеют экспоненциальное распределение, имеется два сервера, длина очереди и число клиентов могут быть сколь угодно большими, а буфер работает по схеме FIFO. Среднее значение длины очереди Q при заданной средней входной частоте сообщений l и среднем времени ожидания W определяется на основе теоремы Литла (1961):
Для варианта очереди M/G/1 входной процесс характеризуется распределением Пуассона со скоростью поступления сообщений l. Вероятность поступления k сообщений на вход за время t равно:
Пусть N – число клиентов в системе, Q – число клиентов в очереди и пусть вероятность того, что входящий клиент обнаружит j других клиентов, равна:
Пj = P[n=j], j=0,1,2,…
Тогда среднее время ожидания w:
(формула Поллажека-Хинчина)
s – среднеквадратичное отклонение для распределения времени обслуживания.
Для варианта очереди M/G/1 H(t) = P[xЈ t] = 1 – e-mt (H – функция распределения времени обслуживания). Откуда следует s2 = t2.
Для варианта очереди m/d/1 время обслуживания постоянно, а среднее время ожидания составляет:
Аналитическая модель для сетей Ethernet (CSMA-CD) разработана Лэмом (S.S.Lam: “A Carrier Sense Multiple Access Protocol for Local Networks,” Computer Networks, vol. 4, n. 1, pp. 21-32, January 1980). Здесь предполагается, что сеть состоит из бесконечного числа станций, соединенных каналами с доменным доступом. То есть станция может начать передачу только в начале какого-то временного домена. Распределение сообщений подчиняется закону Пуассона с постоянной скоростью следования l. Среднее значение времени ожидания для таких сетей составляет:
где е – основание натурального логарифма, t - задержка распространения сигнала в сети.
, где 
. Рассмотрим вариант сети Ethernet на основе концентратора-переключателя с числом каналов N. При этом будет предполагаться, что сообщения на входе всех узлов имеют пуассоновское распределение со средней интенсивностью li, распределение сообщений по длине произвольно. Сообщения отправляются в том же порядке, в котором они прибыли. Трафик в сети предполагается симметричным. Очередь имеет модель M/G/1. Среднее время ожидания в этом случае равно:
где
Для больших n это приводит к
Среднее время распространения сообщения в сети равно
4.5.17.2 Симуляционное моделирование
Симуляционное (статистическое) моделирование служит для анализа системы с целью выявления критических элементов сети. Этот тип моделирование используется также для предсказания будущих характеристик системы. Такое моделирование может осуществляться с использованием специализированных языков симулирования и требует априорного знания относительно статистических свойств системы в целом и составляющих ее элементов. Процесс моделирования включат в себя формирование модели, отладку моделирующей программы и проверку корректности выбранной модели. Последний этап обычно включает в себя сравнение расчетных результатов с экспериментальными данными, полученными для реальной сети.
При статистическом моделировании необходимо задать ряд временных характеристик, например:
Системное время
Время ожидания
Время распространения
Время передачи
В процессе моделирования рассчитываются следующие параметры:
Статистика очередей |
| Средняя длина очереди |
| Пиковая длина очереди |
| Среднеквадратичное отклонение длины очереди от среднего значения |
Статистика времени ожидания |
| Среднее время ожидания |
| Максимальное время ожидания |
| Среднеквадратичное отклонение времени ожидания |
Статистика системного времени |
| Среднее системное время |
| Максимальное системное время |
| Среднеквадратичное отклонение системного времени |
| Полное число сообщений в статистике системного времени |
| Пиковое значение числа системных сообщений |
| Среднеквадратичное отклонение числа системных сообщений |
Статистика потерь сообщений |
| Полное число потерянных сообщений |
| Частота потери сообщений |
| Доля потерь из-за переполнения очереди |
| Доля потерь из-за таймаутов |
/p> Разумеется, реальный перечень вычисляемых параметров может быть существенно шире и определяется конкретными целями расчетов. Рассмотрим частную задачу определения среднего числа связей между процессорами (узлами). Предполагается, что полное число узлов равно N, а схема соединения узлов соответствует изображенной на рис. 4.5.7.1.
Рис. 4.5.7.1.
Среднее расстояние от произвольного узла до всех остальных узлов равно D(N+1)/3, где D – расстояние между соседними узлами (предполагается константой).
Возможны разные подходы к моделированию. Классический подход заключается в воспроизведении событий в сети как можно точнее и поэтапное моделирование последствий этих событий. В реальной жизни события могут происходить одновременно в различных точках сети. По этой причине для моделирования идеально подошел бы многопроцессорный компьютер, где можно воспроизводить любое число процессов одновременно. В любом случае необходимо выбрать некоторый постоянный временной интервал и считать, что события произошли одновременно, если расстояние между ними меньше этого интервала. Для сетей типа ethernet таким временным интервалом может быть бит-тайм (для 10-мегагбитного ethernet это 100нс). Понятно, что это уже отступление от реальности (ведь задержки в сетевом кабеле не кратны этому времени), но не слишком значительное. Надо сказать, что такого рода предположений при моделировании приходится делать много. По этой причине крайне важно сравнивать результаты моделирования с данными, полученными для реальной сети. Если отличия лежат в пределах 10-20%, можно считать, что сделанные предположения не увели программу слишком далеко от жизни и ею можно пользоваться для расчетов. Рассмотренный выше подход пригоден для моделирования сетевого коллапса, так как скорость расчетов здесь зависит от числа узлов и почти не зависит от сетевой загрузки.
Другим подходом может стать метод, где для каждого логического сегмента (зоны столкновений) сначала моделируется очередь событий. При этом в каждой рабочей станции моделируется последовательность пакетов, ожидающих отправки. Эта очередь может время от времени модифицироваться, например, при получении ЭВМ пакета извне и необходимости послать на него отклик. После того как такая очередь для каждого сетевого объекта (сюда помимо ЭВМ входят мосты, переключатели и маршрутизаторы) построена, запускается программа отправки пакетов. При этом выбирается самый первый по времени пакет (ожидающий дольше других) и проверяются для него условия начала передачи (отсутствие несущей на входе сетевого интерфейса в данный момент и в течение 9,6 мксек до рассматриваемого момента -96 тайм-битов). Если условия отправки выполнены, он “посылается” в сеть. Вычисляются моменты достижения им всех узлов данного логического сегмента, проверяются условия его столкновения с другими пакетами. Следует заметить, в этом подходе снимается ограничения “дискретности” временной шкалы, использованной в предыдущем “классическом” подходе. Этот подход позволяет заметно ускорить расчеты при большом числе узлов, но малой загрузке сети. Проблемы реализации данной концепции моделирования связаны с обслуживанием довольно сложного списка, описывающего очередь пакетов, ожидающих отправки. В структуру этого списка включается и описание ситуации в сети на данный временной период. Дополнительные трудности сопряжены с поведением мостов, переключателей и маршрутизаторов, так как они могут вставлять в очередь дополнительные элементы, требующие немедленного обслуживания. Аналогичные вставки в очередь будут вызывать полученные станцией пакеты ICMP или TCP, требующие откликов. Причем такое вставление в очередь асинхронно по отношению к процедуре “отправки” пакетов. Очередь для всей локальной сети может быть единой, тогда пакеты разных логических сегментов должны быть помечены определенными флагами. При переходе из сегмента в сегмент флаг будет меняться. Возможно и построение независимых очередей для каждого из логических сетевых сегментов.
Целью моделирования является определение зависимости пропускной способности сети и вероятности потери пакета от загрузки, числа узлов в сети, длины пакета и размера области столкновений.
Исходные данные о структуре и параметрах сети берутся из базы данных. Ряд параметров сети задаются конфигурационным файлом (профайлом). Сюда могут записываться емкость буфера интерфейса и драйвера, время задержки обработки запроса (хотя в общем случае эта величина может также иметь распределение) и т.д.. К таким параметрам относятся также: MTU, MSS, TTL, window, некоторые значения таймаутов и т.д.
Сеть разбивается на логические сегменты (зоны столкновений), в каждой из которых работает независимая синхронизация процессов (хотя эти процессы и влияют друг на друга через мосты, переключатели и маршрутизаторы).
Полное моделирование сети с учетом рабочих приложений предполагает использование следующих распределений:
Распределение по проценту времени использования каждого из узлов для того или иного вида приложений.
Распределение узлов сети по их активности.
Распределение по используемым протоколам
Распределение по длинам пакетов.
Последние два пункта существенным образом коррелированы с первым, так как используемые протоколы зависят от приложения, а активность узла может определяться, например длиной пересылаемого файла. По этой причине при полномасштабном моделировании сначала определяется, что собирается делать рабочая станция или сервер, (с учетом распределения по приложениям определяется характер задачи: FTP, MS explorer и т.д.). После этого разыгрываются параметры задания (длина файла, удаленность объекта и пр.), а уже на основе этого формируется фрагмент очереди пакетов.
Задача первого этапа
: проверка пропускной способности при вариации загрузки и длин пакетов, подсчет числа столкновений, проверка влияния размера буфера сетевого интерфейса на пропускную способность (влияние размера буфера переключателей по пути до адресата).
Исходные данные для первого этапа:
частота посылки пакетов для каждого из узлов (в начале равная для всех) [d - интервал между пакетами]
длина пакета, посылаемого каждым узлом, (в начале равна для всех: минимальная [512 бит] и максимальная [12000 бит])
временное распределение моментов посылки пакетов (в начале равномерное)
Структура описания каждого из узлов включает в себя (формируется с учетом будущего расширения):
Номер узла (идентификатор)
Код типа узла (байт: рабочая станция, мост, переключатель, маршрутизатор, повторитель)
mac-адрес (для повторителя =0)
ip-адрес (для повторителя, обычного MAC-моста и переключателя =0)
Байт статуса (узел ведет передачу; до узла дошел чужой пакет,….)
d (среднее расстояние между концом предыдущего и началом очередного пакета в бит-тактах)
Дисперсия ширины пакетов
Дисперсия значения d (зазор между последовательными пакетами).
Код используемого протокола (IPv4 или IPv6; TCP, UDP, ICMP и т.д.).
Полная длина сообщения в байтах
Время обработки пакета (задержка посылки отклика в бит-тактах)
Длина очередного пакета
Байт типа адресации (unicast, broadcast, multicast)
Ширина окна (число отправляемых пакетов без подтверждения)
Объем входного буфера (число пакетов; может измеряться и в байтах, но тогда нужны специальные указатели)
Объем выходного буфера (число пакетов)
Байт режима работы (для мостов и переключателей: cut-through; store-and-forward и т.д.; для рабочей станции определяется типом используемого протокола и фазой его реализации)
Формат описания топологии сети (список)
Элемент списка:
Идентификатор узла (номер)
Код типа узла
Список узлов соседей (номер_соседа:задержка_до_него)
Процесс посылки пакета включает в себя (в соответствии с требованиями документа IEEE 802.3):
Проверку возможности начала (отсутствует чужая активность, ipg=9,6 мксек)
Последовательную передачу битов (каждый бит-такт)
Контроль состояния столкновений (на протяжении времени, соответствующего диаметру столкновений сегмента сети)
Обработка случаев столкновения (посылка jam)
При столкновении вычисление номера бит-такта попытки возобновления передачи
Попытка начала передачи предполагает проверку:
Осуществлялась ли передача на предыдущем бит-такте?
Контроль числа свободных от передачи бит-тактов (<96 ?)
Процесс приема предполагает:
Контроль окончания приема (бит-такт без данных в канале). Окончание приема может означать переход в режим анализа полученных данных.
Контроль наличия столкновения
Необходимо предусмотреть возможность (в некоторых режимах) контроля адресов (mac и ip) и содержимого пакета и т.д. (включая изменение режима работы узла, например, переход от чтения к передаче). Данный пункт абсолютно необходим для мостов и переключателей.
Центральный менеджер осуществляет:
Регистрацию начала передачи любым из узлов (номер узла и номер бит-такта)
Расчет положения начала пакета к началу очередного бит-такта для всех возможных путей распространения.
Запись в байты статуса узлов
Вариант 1 (равномерное распределение по времени)
Для каждого узла устанавливается определенная средняя частота посылки пакетов. Время посылки предполагается случайным. Средняя частота может быть задана равной для всех узлов. Так как минимальный размер пакета равен 64 байт (51.2 мксек=512 бит-тактов), максимальная частота посылки пакетов составляет ~19.5 кГц.
Минимальный средний период посылки пакетов определяется в бит-тактах и должен быть больше 512 бит-тактов. Понятно, что пока узел осуществляет передачу, он не может пытаться передать новый пакет (многозадачные, многопользовательские системы с несколькими сетевыми интерфейсами пока рассматривать не будем). По этой причине частота посылки пакетов однозначно определяется паузой между концом предыдущего пакета и началом нового (d). Среднее значение периода посылки пакетов равно Тпакета+96(бит-тактов)+d (значение d величина статистическая). Для каждого узла задается значение d (сначала равное для всех узлов). Если предположить равномерное распределение вероятности (передача пакета может начаться в любой бит-такт с равной вероятностью).
При определении того, пытаться ли начинать передачу в данный бит-такт будет проверка условия:
rndm<1/d
( выполнение условия предполагает попытку начала передачи).
Если вероятность прихода n пакетов на время t распределена по закону Пуассона:
Результатами моделирования могут являться (
фиксируются отдельно для каждого набора входных параметров):
| 1. | Вероятность потери пакета для логического сегмента и каждой из рабочих станций. |
| 2. | Пропускная способность серверов для каждого из логических сегментов (путь сервер -> логический сегмент) |
| 3. | Вероятность столкновения для каждого логического сегмента и каждой рабочей станции. |
| 4. | Распределение потоков по логическим сегментам (и рабочим станциям) независимо для каждого направления (вход и выход). |
| 5. | Распределение потоков для всех входов/выходов переключателей мостов и маршрутизаторов. |
| 6. | Доля вспомогательного трафика (ICMP, SNMP, отклики TCP, широковещательные запросы и т.д.) по отношению к информационному потоку для различных узлов сети (серверов, маршрутизаторов) |
| 7. | Уровень широковещательного трафика для каждого из логических сегментов |
Сетевой протокол времени NTP
4.4.15 Сетевой протокол времени NTP
Семенов Ю.А. (ГНЦ ИТЭФ)
Время – самый важный и невосполнимый ресурс любого человека. Проблема эта занимала людей всегда, и уже более 4 тысяч лет люди пытаются как-то упорядочить учет расходования этого ресурса, создавая различные календарные системы и устройства измерения времени. Календарные системы древнего мира отражали сельскохозяйственные, политические и ритуальные нужды, характерные для того времени. Астрономические наблюдения для установления зимнего и летнего солнцестояния производились еще 4000 лет тому назад. Проблема создания календаря возникала только в обществах, где государственная стабильность поддерживалась в течение достаточно долгого времени (Китай, Египет, государство Майя). В 14-ом столетии до Рождества Христова в Китае была определена длительность солнечного года - 365.25 дней, а лунный месяц - 29.5 дней. Солнечно-лунный календарь действовал на ближнем востоке (за исключением Египта) и в Греции, начиная с 3-го тысячелетия до нашей эры. Ранние календари использовали либо 13 лунных месяцев по 28 дней или 12 месяцев с чередующейся протяженностью 29 и 30 дней.
Древнеегипетский календарь имел 12 30-дневных лунных месяцев, но был привязан к сезонному появлению звезды Сириус (sirius – sothis). Для того чтобы примирить этот календарь с солнечным годом, был изобретен гражданский календарь, в котором добавлено 5 дней, доводящих длительность года до 365 дней. Однако со временем было замечено, что гражданский год примерно на одну четверть дня короче, чем солнечный год. Выбранная длительность года обеспечивала полное совпадение с солнечным годом раз за 1460 лет. Этот период называется циклом Сотиса (sothic-цикл). Так же как и shang chinese, древние египтяне установили длительность солнечного года равной 365,25 дней, что с точностью 11 минут совпадает с результатами современных вычислений. В 432 году до рождества Христа, около столетия после китайцев греческий астроном Метон вычислил, что 110 лунных месяцев по 29 дней и 125 лунных месяцев по 30 дней соответствуют 6940 солнечным дням, что лишь немного превышает 19 лет. 19-летний цикл, названный циклом Метона, установил длительность лунного месяца равной 29,532 солнечных дней, что с точностью 2 минут совпадает результатами современных измерений.
В древнем Риме использовался лунный календарь. Юлий Цезарь пригласилалександрийского астронома Сосигенса, который разработал календарь (который по понятным причинам стал называться юлианским), принятый в 46 году до Рождества Христова. Календарь содержал 365 дней в году с добавлением одного дня каждые 4 года. Однако первые 36 лет по ошибке дополнительный день добавлялся каждые три года. В результате набежало лишних три дня, которые пришлось компенсировать вплоть до 8 года нашей эры.
Семидневная неделя была введена лишь в четвертом столетии нашей эры императором Константином I.
Во время романской эры 15-летний цикл переписи использовался при исчислении налогов. Последовательность имен дней недели воспроизводится через 28 лет, этот период называется солнечным циклом. Таким образом, учитывая 28-летний солнечный цикл, 19-летний цикл Метона и 15-летний переписи, получаем суперцикл протяженностью 7980-лет, называемый юлианской эрой, которая начинается в 4713 году до рождества христова.
К 1545 году расхождение между юлианским календарем и солнечным годом достигло 10 дней. В 1582, астрономы Кристофер Клавиус и Луиджи Лилио предложили новую схему календаря. Папа Грегорий XIII выпусти указ, где среди прочего указывалось, что в году содержится 365.2422 дней. Для того чтобы более точно аппроксимировать эту новую величину, только столетние годы, которые делятся без остатка на 400, объявляются високосными, что предполагает длительность года 365,2425 дней. В настоящее время григорианский календарь принят большинством стран мира.
Для того чтобы мерить расширение вселенной или распад протона необходимо стандартную схему нумерации дней. По решению Международного астрономического Союза был принят стандарт на секунду и юлианская система нумерации дней (jdn). Стандартный день содержит 86,400 стандартных секунд, а стандартный год состоит из 365,25 стандартных дней.
В схеме (JDN), предложенной в 1583 французским ученым Джозефом Юлиусом Скалигером, JDN 0.0 соответствует 12 часам (полдень) первого дня юлианской эры - 1 января 4713 до нашей эры. Годы до нашей эры подсчитываются согласно юлианскому календарю, в то время как годы нашей эры нумеруются по григорианскому календарю. 1 января 1 года после рождества христова в григорианском календаре соответствует 3 января 1 года юлианского календаря [DER90], в JDN 1.721.426,0 день соответствует 12 часам первого дня нашей эры.
Калиброванный эталон времени, например атомные часы, довольно сложное и дорогостоящее устройство, требующее квалифицированного обслуживания. По этой причине многие пользователи не могут позволить себе такие издержки и вынуждены обращаться к услугам удаленных эталонов. Это может быть первичный эталон, размещенный где-то в локальной сети, или радио-часы. Условия доступа к сети уже предполагают наличие определенной дисперсии для времени доставки калибровочной информации. Если же эталон размещен далеко в Интернет, значения задержки и дисперсии могут возрасти многократно. Для обеспечения большей надежности калибровки обычно используют несколько эталонов, а для снижения влияния временных разбросов привлекают довольно сложные алгоритмы усреднения.
Сетевой протокол задания времени NTP (network time protocol; Network Time Protocol Version 3 Specification, Implementation and Analysis, David L. Mills, RFC-1305, March 1992) служит для осуществления синхронизации работы различных процессов в серверах и программах клиента. Он определяет архитектуру, алгоритмы, объекты и протоколы, используемые для указанных целей. NTP был впервые определен в документе RFC-958 [MIL85c], но с тех пор несколько раз переделан и усовершенствован (RFC-1119 [MIL89]). Протокол использует для транспортных целей UDP [POS80]. Целью протокола является обеспечение максимально возможной точности и надежности, несмотря на значительный разброс задержек при прохождении через большое число промежуточных маршрутизаторов.
Протокол NTP обеспечивает механизмы синхронизации с точностью до наносекунд. Протокол предлагает средства для определения характеристик и оценки ошибок локальных часов и временного сервера, который осуществляет синхронизацию. Предусмотрены возможности работы с иерархически распределенными первичными эталонами, такими как синхронизуемые радио-часы.
Точность, достижимая с помощью NTP, сильно зависит от точности локальных часов и характерных скрытых задержек. Алгоритм коррекции временной шкалы включает внесение задержек, коррекцию частоты часов и ряд механизмов, позволяющих достичь точности порядка нескольких миллисекунд, даже после длительных периодов, когда потеряна связь с синхронизирующими источниками.
Существует ряд механизмов в Интернет, которые позволяют передавать и записывать время, когда произошло какое-то событие. Это протокол daytime [POS83a], time protocol [POS83b], сообщения ICMP “временная метка” [DAR81b] и опция IP “временная метка” [SU81].
Маршрутный протокол fuzzball [MIL83b], иногда называемый hellospeak, встраивает синхронизацию непосредственно в алгоритм маршрутного протокола. Он не является протоколом из стека IP.
Юниксовский (4.3BSD) времязадающий демон [GUS85a] измеряет временные сдвиги различных клиентских процессов и рассылает им соответствующие поправки.
В этой модели сервер определен с помощью алгоритма выбора [GUS85b], который исключает ситуации, где сервер не выбран или выбрано более одного сервера. Процесс выбора требует возможности рассылки широковещательных сообщений.
Архитектура системы
В модели NTP некоторое число первичных эталонов времени, синхронизованных по кабелю или с помощью национальных радио служб времени, подключено к широкодоступным ресурсам, таким как порты опорной сети. Эти устройства функционируют как первичные серверы времени. Целью NTP является передача информации о точном времени от этих серверов к другим серверам через Интернет и коррекция ошибок, связанных с флуктуациями задержек в сети. Некоторое число локальных ЭВМ или внешних шлюзов могут выполнять функции вторичных серверов времени, общающихся с первичными эталонами на основе протокола NTP. Вторичные серверы позволяют минимизировать избыточность протокола, рассылая нужную временную информацию локально. В целях обеспечения надежности выбранные вторичные источники могут быть снабжены менее точными, зато более дешевыми радио-часами, используемыми в ситуациях, когда откажет первичный эталон или выйдет из строя ведущий к нему канал.
Под стабильностью подразумевается степень постоянства задающей частоты часов, а под точностью – соответствие этой частоты национальным стандартам времени. Если не указано обратного, под временным сдвигом между часами подразумевается разница показаний этих часов. В то время как под сбоем (skew) подразумевается различие их рабочих частот (первая производная). Настоящие часы имеют конечную стабильность частоты (вторая производная не равна нулю). Нестабильность частоты называется дрейфом, но в рамках протокола NTP дрейф предполагается равным нулю.
Протокол NTP создан с целью определения трех величин: смещения часов (clock offset), RTT и дисперсии, все они вычисляются по отношению к выбранным эталонным часам. Смещение часов определяет поправку, которую необходимо внести в показания местных часов, чтобы результат совпал показанием эталонных часов. Дисперсия характеризует максимальную ошибку локальных часов по отношению к эталонным.
В протоколе NTP нет средств для нахождения партнера или управления. Целостность данных обеспечивается с помощью IP и UDP контрольных сумм. Система может работать в симметричном режиме, когда сервер и клиент неразличимы, и в режиме клиент-сервер, где сервер выполняет только то, что требует клиент. Используется только один формат сообщений NTP. В рамках модели необходимо определить минимально возможную частоту коррекций часов, обеспечивающую требуемую временную точность.
Реализация модели
Клиент посылает NTP-сообщения одному или нескольким серверам и обрабатывает отклики по мере их получения. Сервер изменяет адреса и номера портов, переписывает содержимое некоторых полей, заново вычисляет контрольную сумму и немедленно посылает отклик. Информация, заключенная в сообщение NTP, позволяет клиенту определить показания часов сервера по отношению к часам клиента и соответствующим образом скорректировать рабочие параметры местных часов. Кроме того, эта информация содержит данные, позволяющие оценить точность и надежность часов сервера и выбрать наилучший эталон времени.
Модель клиент-сервер может быть вполне достаточна для локальных сетей, где один сервер обслуживает некоторое количество клиентов. В общем случае NTP требует одновременной работы большого числа распределенных пар партнеров (клиент-сервер), конфигурация которых изменяется динамически. Нужны достаточно сложные алгоритмы управления такой ассоциацией, для обработки данных и контроля множества локальных часов.
Процесс передачи, управляемый независимыми таймерами для каждого из партнеров, осуществляет накопление информации в базе данных и посылает сообщения NTP. Каждое сообщение содержит локальную временную метку момента отправки сообщения, ранее полученные временные метки, а также необходимую вспомогательную информацию. Частота посылки сообщений определяется требуемой точностью локальных часов, а также предельными точностями часов партнеров.
Процесс приема осуществляет получение сообщений NTP и, возможно, сообщений других протоколов, а также информации от непосредственно подключенных радио-часов. Когда получено сообщение NTP, вычисляется сдвиг между часами партнера и локальными часами, результат заносится в базу данных вместе с другой информацией, необходимой для вычисления ошибок и выбора партнера.
Конфигурации сети
Субсеть синхронизации представляет собой соединение первичных и вторичных серверов времени, клиентов и каналов передачи данных. Первичные серверы времени синхронизованы непосредственно от эталонов времени, обычно от радио-часов. Вторичные серверы могут быть синхронизованы от первичных серверов или других вторичных серверов времени. Система серверов имеет иерархическую структуру, построенную по схеме клиент-сервер. Понятно, что вторичные серверы обеспечивают более низкую временную точность.
Следуя принципам, принятым в телефонной промышленности [BEl86], точность каждого сервера определяется номером слоя (stratum), наивысший уровень (для первичного сервера) имеет номер 1. На современном уровне технологий (радио-часы) точность однократной сверки имеет порядок одной миллисекунды.
Точность однократной сверки падает по мере роста значения RTT и его разброса. Для того чтобы избежать сложных расчетов [BRA80], необходимых для оценки точности в каждом конкретном случае, полезно предположить, что средняя ошибка измерения пропорциональна RTT и ее дисперсии. Предполагая, что первичные серверы синхронизованы стандартами времени с известной точностью, можно получить вполне надежную оценку точности синхронизации субсети.
Дополнительным фактором является то, что каждый переход от одного слоя к другому предполагает наличие ненадежного сервера времени, который вносит дополнительные ошибки. Алгоритм выбора серверов времени использует разновидность алгоритма маршрутизации Беллмана-Форда, при этом формируется дерево минимальных весов, основанием которого являются первичные сервера. Метрикой расстояния служит номер слоя плюс расстояние синхронизации, которое характеризуется суммой дисперсии и половины абсолютного значения задержки.
Такая конструкция способствует тому, что субсеть автоматически реконфигурируется и настраивается на максимально достижимую точность даже при выходе из строя первичных или вторичных серверов времени. Если даже все первичные серверы выйдут из строя или станут недоступными, их функции будут выполнять вторичные серверы, если расстояние до них согласно алгоритму Беллмана-Форда не превышает значения метрики, соответствующего бесконечности (разрыву связи). Если все серверы окажутся на больших расстояниях, субсеть продолжит работу при установках, выполненных при последней синхронизации (коррекции внутренних часов). Даже в этом случае достижима точность порядка миллисекунд в сутки.
Если два сервера находятся согласно алгоритму на равных расстояниях, допускается случайный выбор.
Форматы данных
Все арифметические операции в рамках протокола выполняются в формате с фиксированной запятой. По этой причине все переменные в NTP имеют именно этот формат. Биты пронумерованы слева на право (со старшего бита), начиная с нуля. Жестких требований на число разрядов после запятой не установлено. Если не оговорено обратного, все числа не имеют знака и занимают все отведенное для них поле (при необходимости в качестве заполнителей старших разрядов используются нули).
Временные метки NTP представляют собой 64-битные числа с фиксированной запятой без знака, которое указывает число секунд с нуля часов 1-го января 1900 года. Целая часть содержит первые 32 разряда, а дробная часть остальные 32 разряда. Этот формат не совпадает с форматом меток ICMP, где время измеряется в миллисекундах. Точность представления составляет 200 пикосекунд, что должно удовлетворить самым экзотическим требованиям.
Временная метка формируется путем копирования показания местных часов. Это производится в момент времени, заданный каким-то событием, например, приходом сообщения. Для поддержания наивысшей точности, важно, чтобы это делалось как можно ближе к оборудованию или программному обеспечению, инициирующего этот процесс. В случае, когда временная метка недоступна, например, производится перезагрузка машин, поле метки характеризуется 64 нулями.
Заметим, что с 1968 года старший бит (бит 0 целой части) равен единице, а где-то в 2036 году 64-битовое поле переполнится.
Переменные состояния и параметры
Ниже приводится обзор различных переменных и параметров, используемых протоколом. Они распределены по классам системных переменных, которые имеют отношение к операционной среде и механизму реализации местных часов. Сюда входят переменные партнеров, которые характеризуют состояние протокольных машин участников обмена, переменные пакетов, описывающие содержимое пересылаемых NTP-сообщений, а также параметры, задающие конфигурацию текущей версии программного обеспечения. Имена переменных записываются строчными буквами, а имена параметров - прописными.
Общие переменные
Следующие переменные являются общими для двух или более систем, партнеров и классов пакетов. Когда необходимо отличить общие переменные с идентичными именами, вводится идентификатор переменной.
Адрес партнера (peer.peeraddr, pkt.peeraddr), порт партнера (peer.peerport, pkt.peerport). 32-битный ip-адрес и 16-битный номер порта партнера.
Адрес ЭВМ (peer.hostaddr, pkt.hostaddr), порт ЭВМ (peer.hostport, pkt.hostport). 32-битный IP-адрес и 16-битный номер порта ЭВМ. Эти переменные включаются в переменные состояния для поддержки мультиинтерфейсных систем.
Индикатор приращения (sys.leap, peer.leap, pkt.leap) - это двухбитный код предупреждения о включении дополнительных секунд во временную шкалу NTP. Эти биты устанавливаются до 23:59 дня добавления и сбрасываются после 00:00 следующего дня. В результате день, для которого проведена эта процедура, окажется длиннее или короче на одну секунду. Для вторичных серверов эти биты устанавливаются протоколом NTP. Биты 0 и 1 (LI) принимают значения, перечисленные в таблице 4.4.15.1:
Таблица 4.4.15.1 Значения кодов индикатора LI
Режим (peer.mode, pkt.mode) - это целое 3-битовое число, обозначающее код режима ассоциации, который может принимать значения, приведенные в таблице 4.4.15.2:
Таблица 4.4.15.2. Значения кодов Режим
| Режим | Значение |
| 0 | зарезервировано |
| 1 | симметричный активный |
| 2 | симметричный пассивный |
| 3 | клиент |
| 4 | сервер |
| 5 | широковещательный |
| 6 | для управляющих сообщений NTP |
| 7 | зарезервировано для частного использования |
Таблица 4.4.15.3. Значения кодов слой
| Слой | Значение |
| 0 | Не специфицирован или недоступен |
| 1 | Первичный эталон (например, радио часы) |
| 2-15 | Вторичный эталон (через NTP или sntp) |
| 16-255 | Зарезервировано на будущее |
Период обмена (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll). Это целая переменная со знаком, указывающая минимальный интервал между передаваемыми сообщениями, измеренный в секундах и представленный как степень 2. Например, значение 6 указывает на минимальный интервал в 64 секунды.
Точность (sys.precision, peer.precision, pkt.precision). Это целая переменная со знаком, обозначающая точность часов в секундах и выраженная как ближайшая степень числа 2. Значение должно быть округлено в большую сторону до ближайшего значения степени 2, например, сетевой частоте 50-Гц (20 мс) или 60-Гц (16.67 мс) будет поставлено в соответствие величина -5 (31.25 мс), в то время как кварцевой частоте 1000-Гц (1 мс) будет поставлено в соответствие значение -9 (1.95 мс).
Базовая задержка (sys.rootdelay, peer.rootdelay, pkt.rootdelay). Это число с фиксированной запятой со знаком, указывающее на величину полной циклической задержки (RTT) до первичного эталона частоты, выраженной в секундах.
Базовая дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion). Это число с фиксированной запятой больше нуля, указывающее на максимальное значение временной ошибки по отношению к первичному эталону в секундах.
Идентификатор эталонных часов (sys.refid, peer.refid, pkt.refid). Это 32-битовый код, идентифицирующий конкретные эталонные часы. В случае слоя 0 (не специфицирован) или слоя 1 (первичный эталонный источник), 4-октетная ASCII-строка, выровненная по левому краю и дополненная при необходимости нулями, например:
Таблица 4.4.15.4. Коды идентификаторов часов
В случае слоя 2 и выше (вторичный эталон) - это 4-октетный IP-адрес партнера, выбранного для синхронизации.
Эталонная временная метка (sys.reftime, peer.reftime, pkt.reftime) - локальное время в формате временных меток, соответствующее моменту последней коррекции показаний часов. Если локальные часы не были синхронизованы, переменная содержит нуль.
Базовая временная метка (peer.org, pkt.org) - локальное время в формате временных меток, соответствующее моменту посылки последнего NTP-сообщения. Если партнер недостижим, переменная принимает нулевое значение.
Временная метка получения (peer.rec, pkt.rec) - локальное время в формате временных меток, соответствующее моменту прихода последнего NTP-сообщения, полученного от партнера. Если партнер недостижим, переменная принимает нулевое значение.
Временная метка передачи (peer.xmt, pkt.xmt) - локальное время в формате временных меток, соответствующее моменту отправки NTP-сообщения.
Системные переменные
Следующие переменные используются операционной системой для синхронизации локальных часов.
Переменная локальные часы (sys.clock) содержит показание локальных часов в формате временных меток. Локальное время получается от аппаратных часов конкретной ЭВМ и дискретно увеличивается с конструктивно заданными приращениями.
Переменная Базовые часы (sys.peer) представляет собой селектор, идентифицирующий используемый источник синхронизации. Обычно это указатель на структуру, содержащую переменные партнера. Значение нуль указывает, что в настоящее время источник синхронизации отсутствует.
Переменные партнера
Ниже перечислены все переменные партнера, которые используются для управления и реализации измерительных процедур.
Бит конфигурации (peer.config) - бит, индицирующий, что ассоциация была сформирована на основе конфигурационной информации и не должна быть расформирована, когда партнер становится недоступен.
Временная метка актуализации (peer.update) - локальное время в формате временной метки, отмечающее момент, когда было получено последнее NTP сообщение. Переменная используется для вычисления дисперсии временного сдвига.
Регистр достижимости (peer.reach) - сдвиговый регистр битов ntp.window, используемых для определения статуса достижимости партнера. Ввод данных производится со стороны младших бит (справа). Партнер считается достижимым, если как минимум один бит этого регистра равен 1.
Таймер партнера (peer.timer) - целочисленный счетчик, используемый для управления интервалом между последовательно посылаемыми NTP-сообщениями. После установки значения счетчика его содержимое уменьшается на 1 (1сек) пока не достигнет нуля. При этом вызывается процедура передачи. Заметим, что работа этого таймера не должна зависеть от локальных часов.
Пакетные переменные
Номер версии (pkt.version) - целое число индицирующее номер версии отправителя. NTP сообщения всегда посылаются с текущим значением версии ntp.version и будут восприняты лишь при условии совпадения кодов версии (ntp.version). Исключения допускаются лишь при смене номера версии.
Переменные фильтра часов
Когда используются фильтры и алгоритмы отбора, дополнительно привлекаются следующие переменные состояния.
Регистр фильтра (peer.filter) - сдвиговый регистр каскадов ntp.shift, где каждый каскад запоминает значения измеренной задержки, смещения и вычисленной дисперсии, соответствующих одному наблюдению. Эти три параметра вводятся со стороны старших разрядов и сдвигаются в направлении младших разрядов (направо). При получении результатов нового наблюдения старые результаты теряются.
Счетчик корректных данных (peer.valid) - целочисленный счетчик, указывающий на корректные образцы, остающиеся в регистре фильтра. Он используется для определения состояния доступности и для управления увеличением и уменьшением периода рассылки сообщений.
Смещение (peer.offset) - число с фиксированной запятой со знаком, индицирующее значение смещение часов партнера по отношению к локальным часам в секундах.
Задержка (peer.delay) - число с фиксированной запятой со знаком, индицирующее полную циклическую задержку (RTT) часов партнера по отношению к локальным часам с учетом времени распространения сообщения и отклика в сети в секундах. Заметим, что переменная может принимать как положительное, так и отрицательное значение в зависимости от точности часов и накопившейся ошибки смещения.
Дисперсия (peer.dispersion) - число с фиксированной запятой, индицирующее максимальную ошибку часов партнера по отношению к локальным часам с учетом сетевой задержки в секундах. Допускаются только значения больше нуля.
Переменные аутентификации
При использовании механизма аутентификации привлекаются следующие переменные состояния.
Бит разрешения аутентификации (peer.authenable) - бит, указывающий, что ассоциация должна работать в режиме аутентификации.
Бит аутентификации (peer.authentic) - бит, индицирующий то, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid) - целое число, идентифицирующее криптографический ключ, использованный при генерации аутентификационного кода сообщения.
Криптографические ключи (sys.key) - набор 64- битных ключей DES. Каждый ключ создается в соответствии с берклиевскими UNIX-распределениями, которые состоят из 8 октетов, где 7 младших бит каждого октета соответствуют битам des 1-7, а старший бит соответствует биту четности DES.
Контрольная крипто-сумма (pkt.check) - криптографическая контрольная сумма, вычисляемая процедурой шифрации.
Параметры
Ниже описаны параметры для всех реализаций, работающих в сети Интернет. Необходимо договориться относительно значений этих параметров для того, чтобы исключить ненужную избыточность и стабилизировать ассоциации партнеров. Приведенные параметры применимы для всех ассоциаций.
Номер версии (ntp.version) - текущий номер версии NTP (3).
Порт NTP (ntp.port) - стандартный номер порта (123), присвоенный протоколу NTP.
Максимальный номер слоя (ntp.maxstratum) - максимальный номер слоя, который может быть использован при кодировании пакетной переменной. Этот параметр обычно интерпретируется как определение бесконечности (недостижимости для протокола маршрутизации в субсети).
Максимальный возраст часов (ntp.maxage) - максимальный интервал в секундах, в течение которого эталонные часы будут рассматриваться корректными после последней сверки.
Максимальный сбой (ntp.maxskew) - максимальная ошибка смещения, связанная со сбоем локальных часов за время ntp.maxage, в секундах. Отношение ntp.maxskew к ntp.maxage интерпретируется как максимальный сбой, вызванный всей совокупностью факторов.
Максимальное расстояние (ntp.maxdistance) - максимально допустимое расстояние между партнерами при синхронизации с использованием алгоритма отбора.
Минимальный период рассылки (ntp.minpoll) - минимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Максимальный период рассылки (ntp.maxpoll) -максимальный период рассылки, допустимый для любого из партнеров в сети Интернет. Этот период выражается в секундах и представляет собой степень 2.
Минимум избранных часов (ntp.minclock) - минимальное число партнеров, необходимое для синхронизации (при использовании алгоритма отбора).
Максимум избранных часов (ntp.maxclock) - максимальное число партнеров, необходимое для организации отбора (при использовании алгоритма селекции).
Минимальная дисперсия (ntp.mindisperse) - минимальное значение приращения дисперсии для каждого из слоев в секундах (при использовании алгоритма фильтрации).
Максимальная дисперсия (ntp.maxdisperse) - максимальная дисперсия в секундах с учетом потерянных данных (при использовании алгоритма фильтрации).
Размер регистра доступности (ntp.window) - размер регистра доступности (peer.reach) в битах.
Размер фильтра (ntp.shift) - размер сдвигового регистра фильтра часов (peer.filter) в каскадах.
Вес фильтра (ntp.filter) - вес, используемый при вычислении дисперсии фильтра (применяется при работе с алгоритмом фильтрации).
Выбранный вес (ntp.select) - вес, используемый при вычислении выбранной дисперсии (применяется при работе алгоритма селекции).
Режимы работы
За исключением широковещательного режима, NTP-ассоциация формируется, когда два партнера обмениваются сообщениями и один или оба из них создает и поддерживает протокольную машину, называемую ассоциацией. Ассоциация может работать в одном из 5 режимов, заданных переменной peer.mode: симметрично активный, симметрично пассивный, клиент, сервер и широковещательный:
Симметрично активный (1). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.
Симметрично пассивный (2). Этот тип ассоциации первоначально создается по прибытии сообщения от партнера, работающего в симметрично активном режиме. Он сохраняется, пока партнер достижим и функционирует в слое ниже или равном данной ЭВМ. В противном случае ассоциация распадается. Однако ассоциация будет существовать до тех пор, пока, по крайней мере, одно сообщение не будет послано в качестве отклика. При работе в этом режиме ЭВМ оповещает о своем намерении синхронизовать и быть синхронизованной партнером.
Клиент (3). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от достижимости или слоя своего партнера. При работе в этом режиме ЭВМ, обычно это сетевая рабочая станция, оповещает о своем намерении быть синхронизованной партнером.
Сервер (4). Этот тип ассоциации первоначально создается по прибытии запроса клиента и существует только для отклика на этот запрос. После отклика ассоциация ликвидируется. При работе в этом режиме ЭВМ, обычно рабочая сетевая станция, оповещает о намерении синхронизовать партнера.
Широковещательный (5). ЭВМ, работающая в этом режиме, периодически посылает сообщения вне зависимости от доступности или слоя партнеров. При работе в этом режиме ЭВМ, обычно сетевой сервер времени, который работает в широковещательной среде, оповещает о намерении синхронизовать всех партнеров.
ЭВМ, работающая в режиме клиента, иногда посылает NTP-сообщение ЭВМ, работающей в режиме сервера, например, сразу после перезагрузки и периодически после этого. Сервер откликается, меняя адреса и номера портов, занося необходимую информацию и отправляя сообщение назад клиенту. Серверы не должны хранить какую-либо статусную информацию в паузах между запросами клиента, в то время как клиенты могут варьировать интервалы между NTP сообщениями, для того чтобы удовлетворить локальным требованиям. В этих режимах протокольная машина, описанная в этой статье, может быть существенно упрощена без заметной потери точности или надежности особенно при работе в быстродействующей локальной сети.
В симметричных режимах отличие клиента от сервера практически исчезает. Симметрично пассивный режим предназначен для использования временными серверами, работающими вблизи базовых узлов (нижний слой) субсети синхронизации и со сравнительно большим числом партнеров. В этом режиме идентификации партнера не требуется заранее, так как ассоциация с ее переменными состояния создана, только когда получено NTP-сообщение. Более того, запомненное состояние может быть использовано позднее, когда партнер станет недостижим или будет работать на более высоком уровне и по этой причине будет непригоден в качестве источника синхронизации.
Симметрично активный режим предназначен для использования серверами времени, работающими вблизи оконечных узлов (наивысший слой) синхронизации. Надежный временной сервис обычно может быть реализован с помощью двух партнеров на ближайшем нижележащем слое и одном партнере в том же слое. По этой причине поток сообщений обычно невелик, даже когда связь потеряна, и на каждый запрос приходит отклик об ошибке.
В норме, один партнер работает в активном режиме (симметричный активный, клиент или широковещательный), как это сконфигурировано в стартовом файле, в то время как другие работают в пассивном режиме (симметричный пассивный или сервер), часто без предварительной конфигурации. Однако оба партнера могут быть сконфигурированы для работы в симметричном режиме. Условие ошибки возникает, когда оба партнера работают в одном и том же режиме, но не в симметричном активном. В таких случаях каждый партнер будет игнорировать сообщения, поступающие от другого, и ассоциация, если она существовала, будет ликвидирована из-за недостижимости партнера.
Широковещательный режим предназначен для работы в скоростных локальных сетях с большим числом рабочих станций, где не требуется высокая точность. При типичном сценарии один или более временных серверов LAN периодически посылают широковещательные сообщения рабочим станциям, которые затем определяют время на основе предварительно заданной задержки распространения порядка нескольких миллисекунд.
Обработка событий
Существенные события с точки зрения протокола NTP происходят при истечении времени таймеров партнера (peer.timer), один из которых ориентирован специально на данного партнера в активной ассоциации, а также при получении NTP-сообщения от различных партнеров. Событие может произойти как результат команды оператора или обнаруженной ошибки, такой как отказ первичного эталона.
Обозначения
Алгоритмы фильтрации и селекции NTP используют несколько переменных для хранения значений сдвига часов, RTT и дисперсии. Переменные, относящиеся к партнерам, обычно обозначаются строчными греческими буквами, а для первичного эталона времени используются прописные буквы. Эти алгоритмы базируются на параметре, называемом расстояние синхронизации
(l) и вычисляемом с использованием rtt и дисперсии.
Дисперсия партнера (e) содержит вклады от ошибок измерения (r) и накопления ошибок дрейфа (skew-error).
Каждый раз, когда соответствующие переменные партнеров изменяются, значения дисперсии корректируются. Ниже приводятся основные определения переменных и формулы их вычисления:
q = peer.offset,
d = peer.delay,
e = peer.dispersion = r + jt + es,
l = e + |d|/2,
где d = rtt, q - сдвиг часов, jt - накопление сбоя, j = ntp.maxskew/ntp.maxage, t - момент времени передачи исходной временной метки (на основе t вычисляется q и d), e
s
- дисперсия фильтра. Переменные, относящиеся к партнеру i, определяются следующим образом:
q i = j i,
d i = peer.rootdelay + d i,
e i = peer.rootdispersion + e
i + j ti
(максимальная дисперсия часов партнера),
li= ei + |di|/2,
Окончательно, предполагая, что для синхронизации выбран i-ый партнер, система переменных определяется следующим образом:
q = комбинированное окончательное смещение (combined final offset),
d = di,
e = ei + ex + q,
l = li,
где ex дисперсия выбора (select dispersion).
Приводимые ниже тексты программ, реализующие вычисления переменных, записаны на условном языке, напоминающем СИ.
Процедура передачи
Процедура передачи запускается, когда таймер партнера станет равным нулю. В режиме клиента с широковещательным сервером сообщения вообще не посылаются. В режиме сервера сообщения посылаются только в качестве отклика на полученные запросы.
Нижеприведенный фрагмент программы инициализирует пакетный буфер и копирует пакетные переменные.
| pkt.peeraddr | /* копирование системных и партнерских переменных */ |
pkt.hostaddr
pkt.hostport
pkt.leap
pkt.version
pkt.mode
pkt.stratum
pkt.poll
pkt.precision
pkt.rootdelay
if (sys.leap = 112 or (sys.clock - sys.reftime) > ntp.maxage)
skew
else
skew j (sys.clock - sys.reftime);
{pkt.rootdispersion
pkt.refid
pkt.reftime
Временная метка передачи pkt.xmt будет использована позднее, для того чтобы проконтролировать отклик. Таким образом, программа должна сохранить точное переданное значение. Кроме того, порядок копирования временных меток должен быть выбран так, чтобы не понизить точность.
| pkt.org | /* копирование временных меток */ |
/p> pkt.rec
pkt.xmt
peer.xmt
Регистр доступности сдвигается на одну позицию влево, в освободившийся разряд записывается нуль. Если все биты регистра равны нулю, вызывается процедура очистки (clear procedure) для обнуления фильтра часов и выбора, если необходимо, нового источника синхронизации. Если ассоциация не была сконфигурирована при инициализации, то она ликвидируется.
| peer.reach | /* актуализация доступности */ |
begin
ликвидируем ассоциацию;
exit;
endif
Если корректные данные введены в сдвиговый регистр фильтра хотя бы раз за время предыдущих двух периодов рассылки (младший бит peer.reach равен 1), счетчик корректных данных увеличивается на 1. После восьми таких удачных периодов интервал рассылки увеличивается. Процедура выбора часов вызывается, если необходимо заменить источник синхронизации.
| if (peer.reach & 6 ? 0) | /* Проверка младших двух бит */ |
| if (peer.valid | /* получены корректные данные */ |
else peer.hostpoll
else begin
| peer.valid | /* ничего не слышно */ |
call clock-filter(0, 0, ntp.maxdisperse);
| call clock-select; | /* выбираем источник синхронизации */ |
call poll-update;
end transmit procedure;
Процедура получения
Процедура получения выполняется по приходу NTP-сообщения. Она проверяет сообщения, интерпретирует различные режимы и вызывает другие процедуры для фильтрации данных и выбора источника синхронизации. Если номер версии в пакете не соответствует текущей версии, сообщение может быть отброшено. Если получено управляющее сообщение NTP и код режима пакета равен 6 (управление), вызывается процедура управляющего сообщения. IP-адреса отправителя и адресата, а также номера портов устанавливаются соответствующими заданному партнеру. Если соответствия нет, производится новая инсталляция протокольной машины и формируется новая ассоциация.
begin receive procedure
if (pkt.version ? ntp.version>) exit;
#ifdef (control messages implemented)
if (pkt.mode = 6) call control-message;
#endef
match addresses and ports to associations;
if (no matching association)
Вызов процедуры дешифровки осуществляется только в случае применения аутентификации.
#ifdef (authentication implemented)
call decrypt;
#endef
Если код режима пакета не равен нулю, он определяет режим на следующем этапе; в противном случае, режим определяется по номеру порта.
| if (pkt.mode = 0) | /* для совместимости со старыми версиями */ |
else
mode
case (mode, peer.hostmode)
В случае ошибки пакет просто игнорируется, а ассоциация, если она не была предварительно сконфигурирована, ликвидируется.
error: if (peer.config = 0) demobilize association;
break;
В случае recv пакет обрабатывается, а ассоциация помечается как достижимая при условии 5-8 успешных проверок. Если и проверки с первой по 4-ую проходят успешно (данные корректны), вызывается процедура коррекции показания локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она ликвидируется.
| recv: call packet; | /* обработать пакет */ |
| if (valid header) begin | /* если правильный заголовок, актуализовать внутренние часы */ |
if (valid data) call clock-update;
endif
else
if (peer.config = 0) ликвидировать ассоциацию;
break;
В случае xmit, пакет обрабатывается и посылается промежуточный отклик. Ассоциация затем ликвидируется.
| xmit: call packet; | /* обработать пакет */ |
| peer.hostpoll | /* послать немедленно отклик */ |
call transmit;
if (peer.config = 0) ликвидировать ассоциацию;
break;
В случае pkt, пакет обрабатывается, а ассоциация помечается как достижимая при условии, что тесты 5-8 (правильный заголовок), перечисленные в пакетной процедуре, прошли успешно. Если, кроме того, прошли тесты 1-4 (корректные данные), вызывается процедура коррекции показаний локальных часов. В противном случае, если ассоциация не была предварительно сконфигурирована, она сразу после отклика ликвидируется.
| pkt: call packet; | /* обработка пакета */ |
| if (valid header) begin | /* если заголовок правилен, поправляется показание местных часов */ |
/p> peer.reach
if (valid data) call clock-update;
endif
else if (peer.config = 0) begin
| peer.hostpoll | /* послать немедленно отклик */ |
call transmit;
ликвидировать ассоциацию;
endif
endcase
end receive procedure;
Пакетная процедура
Пакетная процедура проверяет корректность сообщения, вычисляет задержку/смещение и вызывает другие процедуры для отбора данных и выбора источника синхронизации. Тест 1 требует, чтобы переданная временная метка отличалась от последней, полученной от того же партнера. Тест 2 требует, чтобы исходная временная метка соответствовала последней метке, посланной тому же партнеру. В случае широковещательного режима (5) rtt=0 и полная точность операции передачи времени будет недостижимой. Однако, полученная точность может быть вполне приемлемой для многих целей. Процедура вызова коррекции времени использует в качестве параметра peer.hostpoll (peer.peerpoll может быть изменено).
begin packet procedure
| peer.rec | /* забрать полученную временную метку */ |
| test1 | /* Тест 1 */ |
| test2 | /* Тест 2 */ |
else begin
| pkt.org | /* потеря временной метки из-за ошибки */ |
| test1; | /* ложные тесты */ |
endif
| peer.org | /* актуализация исходной временной метки */ |
| peer.peerpoll | /* скорректировать период рассылки */ |
Тест 3 требует, чтобы исходная и полученная временные метки не были равны нулю. Если любая из них равна нулю, ассоциация не синхронизирована или потеряла доступ в одном или обоих направлениях.
test3
rtt и временное смещение по отношению партнера вычисляется следующим образом. Пусть i четное целое число.
Тогда ti-3, ti-2, ti-1 и ti - содержимое переменных pkt.org, pkt.rec, pkt.xmt и peer.rec, соответственно. Смещение часов j, rtt=d и дисперсия e ЭВМ по отношению к партнеру равны:
d = (ti - ti-3) - (ti-1 - ti - 2),
j = ((ti - 2 - ti-3) + ( ti-1 - ti))/2,
e = (1 j (ti - ti-3),
где, как и прежде, j = ntp.maxskew/ntp.maxage. e представляет собой максимальную ошибку или дисперсию, связанную с ошибкой измерения на стороне ЭВМ, а также накопление ошибок из-за дрейфа локальных часов за время после посылки последнего сообщения, посланного партнером. Дисперсия корректируется процедурой фильтра часов (clock-filter).
Рассмотренный метод эквивалентен непрерывному стробированию, которое используется в некоторых телефонных сетях [bel86]. Преимуществом метода является полная независимость от порядка и времени прихода сообщений, а также допустимость потери некоторых пакетов. Очевидно, что достижимые точности зависят от статистических свойств каналов связи.
Тест 4 требует, чтобы вычисленная задержка лежала в допустимых пределах:
test4 d| < ntp.maxdisperse И e
Тест 5 используется, только если реализован механизм аутентификации. Он требует, чтобы либо аутентификация была явно блокирована, либо чтобы аутентификатор в точности соответствовал тому, что описано в процедуре дешифровки.
#ifdef (authentication implemented) /* Тест 5 */
test5
#endef
Тест 6 требует, чтобы часы партнера были синхронизованы, и время с момента последней коррекции было положительным и меньше чем ntp.maxage.
Тест 7 гарантирует, что ЭВМ не будет синхронизовано от партнера с большим кодом номера слоя.
Тест 8 требует, чтобы заголовок содержал соответствующие коды в полях pkt.rootdelay и pkt.rootdispersion.
| test6 2 and | /* Тест 6 */ |
| test7 | /* Тест 7 */ |
| test8 | /* Тест 8 */ |
С точки зрения последующей обработки пакеты содержат корректные данные, если успешно проходят тесты 1-4 (test1 & test2 & test3 & test4 = 1), вне зависимости от результатов других тестов. Только пакеты с корректными данными могут использоваться для вычисления смещения (offset), задержки (delay) и дисперсии. Пакеты имеют корректные заголовки, если успешно проходят тесты 5-8 (test5 & test6 & test7 & test8 = 1), вне зависимости от результатов остальных тестов. Только пакеты с корректными заголовками могут использоваться для определения того, может ли партнер быть выбран в качестве источника синхронизации. Заметим, что тесты 1-2 не используются в широковещательном режиме.
Процедура "часовой фильтр" вызывается для вычисления задержки (peer.delay), смещения (peer.offset) и дисперсии (peer.dispersion) для партнера. Спецификация алгоритма часового фильтра не является составной частью протокола NTP. По этой причине описания, приводимые ниже, следует рассматривать как рекомендательные.
if (not valid header) exit;
| peer.leap < pkt.leap; | /* Копирование переменных пакета */ |
peer.precision ;
peer.rootdelay ;
peer.rootdispersion ;
peer.refid ;
peer.reftime ;
| if (valid data) call clock-filter(q, d, e); | /* обработка данных */ |
Процедура коррекции показаний часов
Процедура коррекции показания часов вызывается процедурой приема, когда процедура фильтрации определила корректные значения смещения задержки и дисперсии для данного партнера.
begin clock-update procedure
| call clock-select; | /* Выбор базовых часов */ |
Может так случиться, что локальные часы оказались сброшены. В этом случае вызывается процедура очистки (clear procedure) для каждого из партнеров, чтобы возвратить в исходное состояние фильтр часов, период рассылки и, если необходимо, осуществить выбор нового источника синхронизации.
Процедура расстояния вычисляет базовую (root) задержку d, базовую дисперсию e и базовое расстояние синхронизации l. ЭВМ не будет синхронизовать выбранного партнера, если расстояние больше чем ntp.maxdistance.
| l andistance(peer); | /* обновление системных переменных */ |
sys.leap
sys.stratum
sys.refid
call local-clock;
| if (local clock reset) begin | /* если сброс, очистить системные переменные */ |
for (all peers) call clear;
endif
else begin
| sys.peer | /* если нет, то подстроить локальные часы */ |
sys.rootdispersion e + max (ex
+ |t|, ntp.mindisperse);
endif
sys.reftime
end clock-update procedure;
В некоторых конфигурациях системы прецизионный источник временной информации доступен в виде последовательности синхронизующих импульсов, следующих с периодом в одну секунду. Обычно это является дополнением к базовому источнику времязадающей информации, такому как радио-часы или даже сам протокол NTP, для того чтобы обеспечить подсчет секунд, минут, часов и дней. В этих конфигурациях системные переменные устанавливаются с учетом источника, от которого поступают такие импульсы. Для конфигураций, которые поддерживают первичные эталонные источники, такие как радио-часы или калиброванные атомные часы код слоя устанавливается равным 1, поскольку именно он является действительным источником синхронизации.
Спецификация алгоритмов выбора часов и работы локальных часов не являются составной частью NTP. По этой причине описания этих алгоритмов, представленные ниже, следует рассматривать лишь как рекомендации.
Работа первичных часов (primary-clock procedure)
Когда ЭВМ связана с первичным эталоном времени, таким как радио-часы, удобно ввести информацию об этих часах в базу данных, как если бы это был обычный партнер. В процедуре первичных часов часы запрашиваются раз в минуту или около того, полученный же временной код используется для корректировки показаний местных часов. Когда обнуляется peer.timer для первичного партнера, процедура передачи не вызывается, а посылается запрос радио-часам с использованием ASCII-последовательности, предусмотренной для этого случая. Когда получен корректный временной код от радио-часов, он преобразуется в формат временной метки NTP и корректируются соответствующие переменные партнера. Величина peer.leap устанавливается в зависимости от состояния бита оповещения временного кода, если таковой имеется, или вручную оператором. Значение для peer.peeraddr, которое становится равно sys.refid, когда вызывается процедура корректировки показаний часов, делается равным ASCII-строке, описывающей часы.
begin primary-clock-update procedure
| peer.leap | /* Копирование переменных */ |
peer.rec
peer.reach
| call clock-filter({sys.clock - peer.rec, 0, 1 | /* образец процесса */ |
| call clockupdate; | /* коррекция локальных часов */ |
Процедуры инициализации
Процедура инициализации вызывается при перезагрузке системы или при повторном запуске демона NTP. Состояние локальных часов при загрузке предполагается неопределенным; однако, некоторые виды оборудования обеспечивают доступ к локальным часам, как в ходе загрузки, так и сразу после нее. Переменная точности определяется внутренней архитектурой оборудования локальных часов. Аутентификационные переменные используются лишь при реализации механизма аутентификации. Значения этих переменных определяются процедурами, выходящими за рамки протокола NTP.
begin initialization procedure
#ifdef (authentication implemented)
sys.keys
#endef;
| sys.leap 2; | /* копирование переменных */ |
sys.precision
sys.rootdelay
sys.rootdispersion
sys.refid
sys.reftime
sys.clock
sys.peer
sys.poll
| for (all configured peers) | /* создание конфигурированных ассоциаций */ |
end initialization procedure;
Процедура initialization-instantiation
Эта процедура является аппаратно-зависимой и служит, среди прочего, для формирования ассоциации. Адреса и режимы работы партнеров определяются в процессе чтения при перезагрузке или в результате обработки команд оператора. В случае привлечения механизма аутентификации только аутентифицированный партнер может стать источником синхронизации.
begin initialization-instantiation procedure
peer.config
#ifdef (authentication implemented)
peer.authenable
peer.authentic
peer.hostkeyid
peer.peerkeyid
#endef;
| peer.peeraddr | /* копирование переменных */ |
peer.hostaddr
peer.hostport
peer.mode
peer.peerpoll
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
Процедура receive-instantiation
Процедура receive-instantiation вызывается процедурой приема, когда обнаруживается новый партнер. Она инициализирует переменные партнера и формирует ассоциацию. Если сообщение получено от партнера, работающего в режиме клиента (3), ЭВМ переводится в режим сервера (4); в противном случае, она устанавливается в симметрично пассивный режим (2).
begin receive-instantiation procedure
#ifdef (authentication implemented)
peer.authenable
peer.authentic
peer.hostkeyid
peer.peerkeyid
#endef
| peer.config | /* Копирование переменных */ |
peer.peerport
peer.hostaddr
peer.hostport
| if (pkt.mode = 3) | /* Определение режима */ |
else
peer.mode
peer.peerpoll
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
Процедура primary clock-instantiation
Эта процедура вызывается из процедуры инициализации для того, чтобы установить переменные состояния для первичных часов. Значение peer.precision определяется из спецификации радио-часов и аппаратного интерфейса. Значение peer.rootdispersion номинально равно удесятеренной максимальной ошибке радио-часов, например, 10 мсек для WWVB или радио-часов goes и 100 мсек для менее точных радио-часов WWV.
begin clock-instantiation procedure
| peer.config | /* копирование переменных */ |
peer.peerport
peer.hostaddr
peer.hostport
peer.leap 2;
peer.mode
peer.stratum
peer.peerpoll
peer.precision
peer.rootdelay
peer.rootdispersion
peer.refid
peer.reftime
peer.timer
peer.delay
peer.offset
| call clear; | /* инициализация ассоциации */ |
В некоторых конфигурациях, включающих в себя атомные часы или приемники LORAN-C, первичный эталон может выдавать только секундные импульсы и не предоставлять полного временного кода (числа секунд и пр.). В этих конфигурациях нумерация секунд может быть получена из других источников, таких как радио-часы или даже другие NTP-партнеры. В этих конфигурациях переменные первичных часов должны отражать особенности первичного эталона, а не источника нумерации секунд. Однако если источник нумерации секунд отказал или работает некорректно, актуализация локальных часов от первичного эталона должна быть заблокирована.
Процедура очистки
Процедура очистки вызывается, когда произошло событие, которое значительно изменило достижимость или вызвало поломку локальных часов.
begin clear procedure
| peer.org | /* пометка неопределенных временных меток */ |
peer.xmt
| peer.reach | /* сброс переменных состояния */ |
| peer.filter | /* все ступени */ |
peer.dispersion
| {peer.hostpoll | /* первичная установка периода рассылки */ |
| call clock-select; | /* Выбор эталонных часов */ |
Процедура запроса-коррекции (poll-update)
Процедура запросов- коррекции вызывается, когда происходит событие, которое может вызвать изменение периода запросов (рассылки) или таймера партнера. Она проверяет значения периода запросов ЭВМ (peer.hostpoll) и партнера (peer.peerpoll), а также устанавливает их в заданных пределах.
begin poll-update procedure
| temp | /* определение периода запросов ЭВМ */ |
temp
else
temp
peer.hostpoll
temp
Если интервал запросов (рассылок) не изменился, а таймер партнера на нуле, то таймер просто сбрасывается в начальное состояние. Если интервал запросов изменен, и новое значение таймера больше текущего значения, никаких дополнительных действий не требуется; в противном случае величина выдержки таймера партнера должна быть уменьшена. Когда время выдержки таймера партнера уменьшается, важно исключить тенденцию синхронизации обмена между партнерами. Благоразумной предосторожностью является рэндмизация первой передачи после уменьшения выдержки таймера.
| if (peer.timer = 0) | /* сброс таймера партнера */ |
else if (peer.timer >temp)
peer.timer
end poll-update procedure;
Процедура расстояния синхронизации (synchronization distance)
Процедура расстояния вычисляет расстояние синхронизации на основе переменных партнеров.
begin distance(peer) procedure;
d
e f (sys.clock - peer.update)};
le + |d|/2;
end distance procedure;
Заметим, что, в то время как d может быть в некоторых случаях отрицательной, e и l всегда положительны.
Замечания о контроле доступа
Конструкция NTP устроена так, что случайная или намеренная модификация данных временного сервера не должна привести к серьезным ошибкам синхронизации. Однако успех этого подхода зависит от дополнительных временных серверов и альтернативных сетевых маршрутов, а также от предположения, что искажения не охватывают большинство временных серверов одновременно. В принципе уязвимость субсети может быть улучшена разумным выбором временных серверов. Механизм аутентификации также позволяет повысить надежность синхронизации. Следует, правда, принимать во внимание, что шифрование/дешифрование данных заметно ухудшает точность синхронизации.
Если требуется более надежная модель, система может базироваться на списке доступа, в который включаются 32-битовый IP-адрес, 32-битовая маска и 3-битовый код режима работы. Если логическое И адреса эталона (pkt.peeraddr) и маски на входе ЭВМ соответствуют соответствующим адресу и режиму (pkt.mode), доступ разрешается, в противном случае отправителю запроса присылается ICMP-сообщение об ошибке. Список управления доступом служит фильтром, определяющим, какой из партнеров может сформировать ассоциацию.
Алгоритмы фильтрации и селекции
Наиболее важным фактором, влияющим на точность и надежность синхронизации, является набор алгоритмов, используемых для уменьшения статистических ошибок и искажений при сбоях в различных компонентах субсети. Алгоритмы, описанные в этой статье, не являются частью стандарта NTP, по этой причине допускается использование любых других алгоритмов.
Для того чтобы NTP алгоритмы фильтрации и отбора работали эффективно, полезно иметь меру вариации для каждого из партнеров. Принятая мера вариации базируется на разностях первого порядка, которые легко вычислить. Существует две меры, одна называемая дисперсией фильтра es, и другая дисперсия выбора (select dispersion) ez. Обе меры вычисляются как взвешенные суммы смещений из списка, сформированного на основе расстояний синхронизации. Если qi (0Ј i < n) смещение i-ой записи, тогда разность eij i-ой записи по отношению к j-ой записи определяется как |qi - q j|. Дисперсия относительно j-ой записи определяется как ej =
где w - весовой коэффициент, который служит для учета влияния расстояния синхронизации на дисперсию. В алгоритмах NTP w выбирается меньше 1/2: w = ntp.filter для дисперсии фильтра (filter dispersion) и w = NTP.SELECT для дисперсии выбора (select dispersion).
Дисперсия es и ex определены относительно 0-ой записи e0.
Существует две процедуры, описанные ниже, процедура "часовой-фильтр" (clock-filter), которая используется для выбора лучших записей смещения для данных часов, и процедура "выбора часов" (clock-selection), которая используется, чтобы выбрать наилучшие часы среди иерархического набора часов.
Процедура часовой фильтр (clock-filter)
Процедура часовой фильтр исполняется по прибытии сообщения NTP или другого события, в результате которого получены новые данные. Она использует аргументы (q, d, e), где q - результат измерения смещения часов, содержащийся в записи, а d и e соответственно RTT и дисперсия. Процедура определяет значение отфильтрованного смещения часов (filtered clock offset - peer.offset), RTT (peer.delay) и дисперсии (peer.dispersion). Она также корректирует дисперсию хранящихся записей и текущее показание часов (peer.update).
Процедура часового фильтра использует сдвиговый регистр (peer.filter), который состоит из NTP.SHIFT каскадов, каждый каскад содержит значения qi, di и e i, которые пронумерованы, начиная с нуля, слева направо. Фильтр инициализируется процедурой очистки при этом заносятся значения [0, 0, NTP.MAXDISPERSE] во всех каскадах. Новые данные записей вдвигаются в фильтр с левого конца. Пакетная процедура выдает записи в формате (q ,d, e), когда приходят новые корректирующие данные, в то время как процедура передачи выдает записи в форме [0, 0, NTP.MAXDISPERSE], когда истекает два периода запроса без поступления свежих данных. Когда одни и те же символы (q, d, e) используютсядля аргументов, содержимого часового фильтра и переменных партнера, их значения обычно понятно из контекста. Ниже представлена псевдопрограмма, поясняющая работу данной процедуры.
begin clock-filter procedure (q, d, e)
Дисперсия ei для всех корректных записей в регистре фильтра должна корректироваться с тем, чтобы отражать накопление смещения со времени последней коррекции. Эти записи заносятся также во временный список, следуя стандартному формату записей [расстояние, индекс]. Записи в регистре сдвигаются вправо, новые записи вводятся слева, а самая правая запись теряется. Временный список сортируется по значению расстояния. Если в списке не остается записей, процедура прерывается без корректировки переменных партнера.
| for (i from ntp.size 1 to 1) begin | /* коррекция дисперсии */ |
/p> [qi, di, ei] q{i-1}, d{i-1}, e{i-1}];
/* shift stage right */
ei = ei + ft;
add [li ? ei + {|di|}/2, i] to temporary list;
endfor;
| [q0, d0, e0] q, d, e]; | /* ввести новую запись */ |
| peer.update | /* сбросить показание часов */ |
где [distance ||index] представляет собой объединение полей расстояния и индекса (расстояние занимает старшую позицию). Дисперсия фильтра es вычисляется и включается в дисперсию партнера. Заметим, что временный список для этой цели уже упорядочен.
es
| for (i from ntp.shift-1 to 0) | /* вычисление дисперсии фильтра */ |
- q0 > NTP.MAXDISPERSE)
es es + NTP.MAXDISPERSE) * NTP.FILTER;
else
es es + |qi
- q0|) * NTP.FILTER;
Смещение партнера q0, задержка d0 и дисперсия e0 выбираются как величины, соответствующие записи с минимальным расстоянием; другими словами, записи, соответствующей первому элементу временного списка (в данной нотации имеет индекс 0).
| peer.offset q0; | /* корректировка переменных партнера */ |
peer.dispersion e0 + es, NTP.MAXDISPERSE);
end clock-filter procedure
Переменные peer.offset и peer.delay представляют смещение шкалы часов и RTT для локальных часов, измеренные относительно часов партнера. Обе они усредняются по большому числу измерений в течение длительного периода времени. Переменная peer.dispersion характеризует максимальную ошибку из-за неточности измерений, дрейфа и вариации записей. Все три переменные используются при выборе часов для синхронизации.
Процедура выбора часов
Процедура выбора часов использует переменные партнера q, d, e и t, она вызывается, когда эти переменные изменились или изменился статус доступности. Процедура включает в себя две составные части: алгоритм пересечения (intersection algorithm) и алгоритм кластеризации (clustering algorithm). Алгоритм пересечения подготавливает список кандидатов партнеров, могущих стать источниками синхронизации и вычисляет доверительный интервал для каждого из них. Алгоритм кластеризации сортирует список кандидатов по кодам слоя и расстояния синхронизации. Системная переменная sys.peer представляет собой указатель на наиболее вероятного кандидата, если таковой имеется, или на нулевую величину в противном случае.
Алгоритм пересечения
begin clock-selection procedure
Каждый из партнеров просматривается последовательно и добавляется в конец списка, если он прошел ряд тестов. Для каждого из m кандидатов в список заносятся 3 записи в форме [указатель, тип]: [q - l, - 1], [q, 0] и [q + l, 1]. В результате в списке будет 3m записей, которые будут позднее упорядочены.
m
| for (each peer) | /*обращение ко всем партнерам */ |
l
| andistance (peer); | /* запись в список */ |
add [q, 0] to endpoint list;
add [q + l, 1] to endpoint list;
m
<B>endif
endfor
| if (m = 0) begin | /* уход, если кандидаты отсутствуют */ |
sys.stratum
exit;
endif
sort endpoint list by increasing endpoint||type;
Ниже приведенный алгоритм представляет собой адаптированную версию DTS [DEC89] и сконструирован так, чтобы отбирать только истинных кандидатов. Алгоритм начинается с инициализации значения f и занесения нуля в счетчики i и c. Затем, начиная с конца упорядоченного, для каждой записи [указатель, тип] значение типа вычитается из кода счетчика i, который содержит число пересечений. Если код типа равен нулю, инкрементируется значение c, которое регистрирует число ложных кандидатов. Если для некоторых записей i і ? m - f, конец записи становится нижней границей пересечения; в противном случае, f увеличивается на 1 и процедура повторяется. Без сброса значений f или c, аналогичная процедура используется для нахождения верхней границы, за исключением того, что значение кода тип добавляется к счетчику. Если после того как обе границы определены c Ј f, процедура продолжается для найденных m - f кандидатов, в противном случае, f увеличивается на 1 и вся процедура повторяется.
| for (f from 0 to f ? m/2) begin | /* обращение ко всем кандидатам */ |
i
| for (each [endpoint, type] from lowest) begin | /* нахождение нижней границы */ |
/p> i
low
if (i ? m - f) break;
if (type = 0) c
endfor;
i
| for (each [endpoint, type] from highest) begin | /* нахождение верхней границы */ |
high
if (i ? m - f) break;
if (type = 0 ) c
endfor;
| if (c ? f) break; | /* продолжить, пока не будут найдены все ложные кандидаты */ |
| if (low > high) begin | /* завершить, если не найдено ни одного пересечения */ |
exit;
endif;
Заметим, что работа продолжается далее данной точки, только если имеется более m/2 пересечений. Однако возможно, но не слишком вероятно, что в области пересечения окажется менее m/2 кандидатов.
Алгоритм кластеризации
В исходном алгоритме DTS процедура выбора часов прерывается в данной точке с выбором кандидатов из центра области пересечения. Однако это ведет к заметной потере точности и стабильности, так как не учитываются индивидуальные статистические свойства партнеров. Следовательно, в NTP только кандидаты, которые остаются в результате описанного выше отбора, могут участвовать в последующей обработке. Список кандидатов преобразуется к форме [расстояние, индекс], где расстояние вычисляется на основе кода слоя и расстояния синхронизации l партнера. Масштабный коэффициент позволяет реализовать механизм весового учета вкладов от кодов слоя и расстояния. Обычно, код слоя доминирует, если только один или более кандидатов имеют слишком большие расстояния. Список упорядочивается согласно величине расстояния.
m
| for (each peer) begin | /* обращение ко всем партнерам */ |
| l | /* сформировать запись в списке */ |
add [dist, peer] to candidate list;
m
endif;
endfor;
sort candidate list by increasing dist;
Последующие шаги служат для того, чтобы отсеять кандидатов со слишком большими дисперсиями. Практика показывает, что число кандидатов здесь может быть достаточно велико. Это может привести к большому числу циклов повторения процедуры отбора, которые не дадут какого-либо улучшения результатов. Длина списка кандидатов ограничивается переменной ntp.maxclock.
Заметим, что exi представляет собой дисперсию относительно i-го партнера из списка кандидатов, которая может быть вычислена методом дисперсии фильтра, описанным выше. ej - дисперсия j-ого партнера из списка, включающая в себя вклады от ошибок измерения, от накопления дрейфа и из-за дисперсии фильтра. Если максимальное значение exi больше чем минимальное значение ej, а число кандидатов больше чем ntp.minclock, i-ый партнер удаляется из списка и процедура повторяется. Если текущий источник синхронизации является одним из членов списка и нет других кандидатов из более низкого слоя, процедура прерывается, и никакие другие последующие шаги не предпринимаются. В противном случае в качестве источника синхронизации берется первый кандидат из списка. В ниже приведенном тексте i, j, k, l - индексы партнеров, k - индекс текущего источника синхронизации (нуль, если такой источник отсутствует), l - индекс первого кандидата в списке.
while begin
| for (each survivor [distance, index]) begin | /* вычисление дисперсии */ |
find index j for min ej;
endfor
if (e{xi} ? ej or m ? NTP.MINCLOCK) break;
| peer.survivor [i] | /* отбрасывание i-го партнера */ |
delete the ith peer from the candidate list;
m
endwhile
if (peer.survivor [k] = 0 or peer.stratum [k] >> peer.stratum [l]) begin
sys.peer
call poll-update;
endif
end clock-select procedure;
Алгоритм сконструирован так, чтобы отдавать предпочтение партнерам из головной части списка, которые размещены в более низком слое, имеют наименьшее расстояние и могут обеспечить наибольшую точность и стабильность. С помощью правильного выбора весового коэффициента v (называемого ntp.select), можно удалить некоторые записи из финальной части списка.
Локальные часы
Для того чтобы иметь точные локальные часы, ЭВМ должна быть оборудована аппаратными часами, состоящими из задающего генератора и интерфейса, обеспечивающего необходимые операции установки и коррекции. Логические часы конструируются, используя эти компоненты и программы, которые осуществляют подстройку частоты и абсолютного показания локальных часов. Такая система позволяет достичь точности времени до 15 нс и стабильности частоты на уровне 0.3 мс в день. Предлагаемая модель удобна для применения как для компенсируемых, так и для некомпенсируемых кварцевых генераторов, пригодна она и для часов, использующих для создания временной шкалы частоту сети переменного тока.
Важно заметить, что конкретная описанная реализация является лишь одной из многих возможных.
Реализация "пушистый шарик" (Fuzzball)
Локальные часы "пушистый шарик" представляют собой комбинация аппаратных и программных регистров, а также алгоритмов, которые осуществляют функционирование часов - работу управляемого задающего генератора, синхронизуемого от внешнего источника. Долее следует описание его компонент и способа работы. Заметим, что все числа представлены в представлении дополнений до 2, а все сдвиги являются арифметическими (заполнение знаком при сдвиге вправо и нулем при сдвиге влево).
48-битовый часовой регистр (clock) и 32-битовый предварительный счетчик (prescaler) образуют управляемый задающий генератор с периодом 1 мс. Дробная часть кода времени представляет число миллисекунд с начала суток. 32-битовый регистр коррекций (Clock-Adjust) используется для подстройки фазы часов постепенными шагами, что исключает неоднородности временной шкалы. Его содержимое обозначается x. 32-битовый регистр компенсации дрейфа (Skew-Compensation) используется для подстройки частоты задающего генератора с помощью добавления небольших фазовых сдвигов (0,01%). Его содержимое обозначается символом y. 16-битовый счетчик оповещения (Watchdog) и 32-битный регистр согласования (Compliance) используются для определения корректности и служит также для задания периода рассылки запросов. Содержимое регистра согласования обозначается символом z. 32-битовый регистр настройки (PPS-Adjust) служит для подстройки точности, когда имеется точный источник сигналов с периодом в одну секунду. 2-битовый регистр флагов управляет добавлением/вычитанием секунд к показаниям часов, когда это необходимо.
Все регистры кроме предварительного счетчика обычно размещаются в памяти. В типовом интерфейсе часов, таком как DEC KWV11-C, регистр prescaler реализован в виде 16-битового буферного счетчика, управляемого кварцевым генератором с частотой, кратной 1000 Гц. Переполнение счетчика вызывает прерывание процессора, которое осуществляет приращение содержимого регистра часов.
Когда наступает момент подстройки, CLOCK. ADJ секунд вычитается из содержимого PPS-счетчика, но это CLOCK.ADJ делается лишь при условии, что там лежит число больше нуля. CLOCK.ADJ добавляется к коду счетчика Watchdog. Этот код не должен превышать значения NTP.MAXAGE, поделенного на CLOCK.ADJ. Если счетчик Watchdog достигнет этой величины, часы считаются не синхронизованными, а Leap-биты устанавливаются равными 112.
Постепенная настройка фазы
Если локальные часы нескорректированы, они продолжают работать со смещением и частотой (при отсутствии дрейфа), установленными при последней коррекции. Корректирующая информация имеет формат 48-битного целого числа со знаком. Это число характеризует целое и дробное число миллисекунд (запятая располагается после 32-го двоичного разряда). Если полученная величина превосходит максимальное значение, заданное CLOCK.MAX, необходима постепенная пошаговая коррекция. В норме величина поправки вычисляется в рамках алгоритма NTP. Однако, если код счетчика PPS больше нуля, вместо него должен использоваться регистр PPS-ADJUST. Пусть u представляет собой 32-битовый код с битами 0-31 равными разрядам 16-47 корректирующего кода. Если некоторые младшие биты корректирующего кода не используются, они устанавливаются равными биту знака. Такие операции сдвигают положение запятой влево по отношению биту 16, что уменьшает влияние ошибок округления. Пусть b число начальных нулей в коде регистра Compliance и пусть c - число начальных нулей в коде счетчика W@atchdog. Тогда b установится равным:
b = b - 16 + clock.comp
b не должно быть меньше нуля (это логарифм постоянной времени обратной связи). Затем установим c равным:
c = 10 - c
Величина c представляет собой логарифм времени интегрирования со времени последней коррекции. Затем вычисляются новые значения кодов для регистров CLOCK.ADJUST и Skew-Compensation.
x = u >> b,
y = y + (u >> (b + b - c)).
В заключение вычисляем экспоненциальное среднее
z = z + (u > clock.weight,
где сдвиг влево переносит положения запятой с целью достижения большей точности.
Для каждого периода подстройки определяется корректирующий код из двух составляющих. Первая составляющая (фаза) определяется как
x >> clock.phase,
эта величина затем вычитается из предшествующего значения регистра Clock-Adjust. Результат становится новым значением кода этого регистра. Вторая компонента - (частота) определяется как
y >> clock.freq.
Совокупность фазы и частоты представляет собой окончательный корректирующий код, который затем добавляется к коду регистра (clock). В заключение, счетчик Watchdog обнуляется.
Величина b вычисленная ранее может использоваться для изменения величины системной переменной, характеризующей период запросов (коррекций) sys.poll.
sys.poll
При условии, что шум коррекций велик, частота аппаратного задающего генератора может меняться быстро из-за изменений условий окружающей среды. В этом случае период запросов укорачивается. Когда шум незначителен, задающий генератор стабилен и период запросов растет вплоть до NTP.MAXPOLL секунд.
Ступенчатая подстройка фазы
Когда величина поправки превышает CLOCK.MAX, имеется возможность того, что часы окажутся настолько не синхронизованы, что наилучшим решением будет немедленная замена содержимого регистра часов. Однако, в случаях, когда вариация записи весьма высока, разумно не поверить в возможность скачкообразного изменения, если только со времени последней коррекции не прошло достаточно много времени. Следовательно, если обнаружено скачкообразное изменение, а счетчик Watchdog содержит код меньше предварительно установленного значения CLOCK.MINSTEP, корректирующее сообщение игнорируется.
Если обнаружено ступенчатое изменение, коррекция заносится непосредственно в регистры Clock, а содержимое регистров Clock-Adjust и Watchdog обнуляется. Другие же регистры остаются без изменений. Так как ступенчатое изменение показаний указывает на некорректность информации в часовых фильтрах (clock filters), биты добавления делаются равными 112 (не синхронизовано) и вызывается процедура очистки часовых фильтров и переменных состояния для всех партнеров. На практике необходимость корректировать показания часов скачкообразно случается крайне редко, когда, например, локальные часы или эталон перезагружаются.
Практически значения CLOCK. MAX могут быть превышены временным сервером лишь в условиях чрезмерной перегрузки канала или при сбоях оборудования. Наиболее часто встречаемый случай - это смена сервера при регистрации слишком большого числа ошибок или из-за сильной вариации задержки. Рекомендуется, чтобы реализации программ включали средства формирования значений CLOCK.MAX для особых случаев. Величина, на которую можно превысить CLOCK.MAX, не нарушая требования монотонности, зависит от значения приращения регистра часов (Clock Register).
Обсуждение реализации
Базовая модель надежности NTP предполагает, что не должно быть никаких других способов изменения показаний кроме предусмотренных самим протоколом NTP. Системы с часами-календарем, имеющие питание от батареи или аккумулятора, считаются надежными, но менее точными, чем использующие NTP-синхронизацию. При последовательных коррекциях, если величина поправки превышает конфигурационный параметр (напр., 1000 секунд), поправка отбрасывается и посылается сообщение об ошибке. Некоторые реализации периодически записывают содержимое регистра Skew-Compensation (компенсация дрейфа) в системный файл или в NVRAM (память, сохраняемая при отключении питания).
Преобразование из формата NTP в обычный информационный формат осуществляется прикладными программами. В день накануне добавления/вычитания секунды из показаний времени значение sys.leap устанавливается на первичном сервере вручную. Следует иметь в виду, что большинство радио-часов не имеет автоматических или ручных средств добавления/вычитания секунд. Но даже в случае некорректного добавления/вычитания секунды локальные часы будут вновь синхронизованы не позднее чем через число секунд, заданное CLOCK.MINSTEP.
Приложение А. Формат данных NTP - версия 3
Формат NTP-сообщения, которое следует сразу после UDP-заголовка, показан на рис 4.4.15.1.
Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.
Рис. 4.4.15.1. Формат сообщения NTP.
Номер версии (VN) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значения кодов режима приведены в таблице 4.4.15.2.
Слой (Stratum) - 8-битовое поле, определяющее код слоя, где работают локальные часы. Коды слоя представлены в таблице 4.4.15.3. Возможные значения кодов лежат в интервале от нуля до NTP.INFIN включительно.
Период запросов (poll interval) - 8-битовое поле, указывающее на максимальное значение интервала между запросами. Код, записанный в этом поле, интерпретируется как целое число со знаком и характеризует значение периода в секундах, как ближайшее к величине степени двух. Коды, которые могут быть записаны в этом поле, должны лежать в интервале между NTP.MAXPOLL и NTP.MAXPOLL включительно.
Точность (precision) - 8-битовое поле, обозначающее точность локальных часов в секундах. Код поля интерпретируется как целая степень со знаком числа 2.
Базовая задержка (Root Delay) - 32-битовое поле, характеризующее RTT до эталонного источника в секундах. Код поля интерпретируется как число с фиксированной запятой, размещенной между битами 15 и 16. Заметим, что величина этого кода может иметь и отрицательное значение (зависит от точности часов и величины дрейфа).
Базовая дисперсия (Root Dispersion) - 32-битовое поле, определяющее максимальную ошибку по отношению к эталонному источнику в секундах. Код поля интерпретируется как число с фиксированной запятой (между 15 и 16 битами). Допустимы только положительные значения.
Идентификатор эталонных часов (Reference Clock Identifier) - 32-битовое поле, идентифицирующее конкретные эталонные часы. В случае кода слоя нуль (не специфицировано) или слоя 1 (первичный эталон), это 4-октетная комбинация выравнивается по левому краю и дополняется нулями (ASCII). Когда идентификатор в NTP не специфицирован, предлагаются ascii- идентификаторы, приведенные в таблице 4.4.15.4.
В случае слоя 2 и больше (вторичный эталон) - это 4-октетный IP-адрес ЭВМ - первичного эталона.
Эталонная временная метка (Reference Timestamp) - поле локального времени (64-битовый формат временных меток), когда часы корректировались в последний раз.
Исходная временная метка (Originate Timestamp) определяет время, когда запрос направлен серверу (стандартный 64-битовый формат временных меток).
Получаемая временная метка (Receive Timestamp) - время, когда запрос прибыл к серверу (стандартный 64-битовый формат временных меток).
Передаваемая временная метка (Transmit Timestamp) - локальное время, когда послан отклик сервером (стандартный 64-битовый формат временных меток).
Аутентификатор (authenticator) (опционно) - поле, содержащее аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.
Приложение Б. Сообщения управления NTP
В сетевой среде должны быть средства управления программами NTP, такие как установка индикатора добавления секунды (Leap-Indicator) со стороны первичного сервера, настройка различных системных параметров и процедур мониторинга. Такие операции могут быть реализованы с привлечением протокола snmp и соответствующего расширения базы данных MIB. Однако в тех случаях, когда такие средства недоступны, эти функции могут быть реализованы с помощью специальных управляющих NTP-сообщений.
Управляющие сообщения NTP имеют код 6 в поле режима первого октета NTP-заголовка. Формат поля данных специфичен для каждой из команд или отклика. Однако, в большинстве случаев формат конструируется так, чтобы облегчить его непосредственное чтение. Как правило, он состоит из ASCII-строк. Если используется аутентификатор, поле данных дополняется нулями до границы, кратной целому числу 32-битных слов.
IP-ЭВМ не должны обрабатывать дейтограммы длиннее 576 октетов; однако, некоторые команды или отклики могут содержать данные, непомещающиеся в одну дейтограмму. Для решения данной проблемы все октеты сообщения нумеруются, начиная с нуля. При передаче фрагментов сообщения номер первого октета записывается в поле смещения (offset), а число октетов в поле длины. Бит (M - more) устанавливается во всех фрагментах за исключением последнего.
Большинство контрольных функций включает посылку команды и получение отклика. Отправитель выбирает ненулевой порядковый номер и устанавливает статусное поле и биты R и E равными нулю. Получатель интерпретирует код операции и дополнительную информацию, содержащуюся в поле данных, вносит изменение в поле статуса и устанавливает бит R=1, а также возвращает три 32-битного слова заголовка вместе с другой дополнительной информацией поля данных. В случае неверного формата сообщения или ошибки в поле данных получатель заносит соответствующий код в поле статуса, устанавливает биты R и E равными 1, и опционно записывает диагностическое сообщение в поле данных.
Некоторые команды осуществляют чтение или запись для системных переменных и переменных партнеров для ассоциации, идентифицированной в команде. Другие читают или записывают значения переменных, связанных с радио-часами и другими приборами, имеющими непосредственное отношение к эталонам времени. Для определения ассоциации используется ее 16-битовый идентификатор. Для системных переменных используется идентификатор нуль. Управляющий объект может затребовать текущий список идентификаторов с тем, чтобы их использовать в дальнейшем. При попытке употребить уже недействительный идентификатор будет прислан соответствующий отклик, после чего необходимо запросить список идентификаторов еще раз.
Некоторые события, такие как изменение статуса доступа к партнеру, не сопряжены с какими-либо командами и происходят асинхронно. Программа может запоминать информацию о таких событиях и пересылать ее в откликах. Текущий статус и краткая аннотация чрезвычайных событий пересылаются каждым откликом. Биты в статусном поле указывают на то, произошло ли какое-либо событие с момента предыдущего отклика и было ли их больше одного.
Формат сообщений управления NTP
Формат заголовков управляющих NTP-сообщений показан на рис. 4.4.15.2. Этот заголовок располагается непосредственно вслед за UDP-заголовком.
Рис. 4.4.15.2. Формат управляющего сообщения ntp
Первые два бита, обозначенные ZZ, должны всегда содержать 0.
Номер версии (VN - version number) - трехбитовое поле, указывающее на номер версии протокола NTP, в настоящее время (3).
Режим (Mode) - трехбитовое поле, определяющее режим, значение кода режима для управляющих сообщений равно 6.
Бит отклика (R) - равен нулю для команд и 1 для откликов.
Бит ошибки (E) - равен нулю для нормального отклика и 1 в случае ошибки.
Бит продолжения (M - more) - равен нулю для последнего фрагмента и 1 - для всех остальных.
Код операции (OP) - 5-битовое поле, определяющее код команды. Значения кодов и их функции представлены в таблице 4.4.15.5.
Таблица 4.4.15.5. Коду операции управляющего сообщения
| Код | Функция |
| 0 | Зарезервировано |
| 1 | чтение статуса команда/отклик |
| 2 | чтение переменной команда/отклик |
| 3 | запись переменной команда/отклик |
| 4 | чтение переменных часов команда/отклик |
| 5 | запись переменных часов команда/отклик |
| 6 | установка адреса/порта trap команда/отклик |
| 7 | отклик на Trap |
| 8-31 | Зарезервировано на будущее |
Статус - 16-битовое поле, содержащее код статуса системы, партнера или часов.
Идентификатор ассоциации (Association ID) - 16-битовое поле, несущее в себе идентификатор ассоциации.
Смещение (Offset) - 16-битовое поле, определяющее положение первого октета поля данных в сообщении, передаваемом в нескольких дейтограммах (позиция задается в октетах).
Длина (Count) - 16-битовое поле, определяющее длину поля данных в октетах.
Данные - это поле содержит информацию сообщения, как для команды, так и для отклика. Максимальное число октетов в поле данных равно 468.
Аутентификатор (опционно). Поле, содержащие аутентификационную информацию. Используется лишь в случае реализации NTP-аутентификации.
Статусные слова
Статусные слова указывают на текущее состояние системы ассоциации и часов. Эти слова интерпретируются программами сетевого мониторинга и имеют 4 разных 16-битовых форматов. Статусные слова партнеров и системы соответствуют откликам для всех команд за исключением случая чтения/записи переменных часов и установки адреса/порта для TRAP. Идентификатор ассоциации нуль соответствует системным статусным словам, в то время как ненулевой идентификатор указывает на какую-то конкретную ассоциацию. Статусное слово, присланное в ответ на команду чтения или записи переменной часов, указывает на состояние оборудования и кодирующего программного обеспечения.
Системные статусные слова
Системное статусное слово может присутствовать в статусном поле отклика. Системное статусное слово имеет следующий формат.
Индикатор добавления (LI - leap indicator) - двухбитовое поле предупреждения о предстоящем добавлении/вычитании секунды к последней минуте текущего дня. Значения этих битов смотри в таблице 4.4.15.1.
Источник часов (clock source) - 6-битовое поле, указывающее на используемый в данный момент источник синхронизации. Назначение кодов этого поля описано в таблице 4.4.15.6.
Таблица 4.4.15.6. Коды источников временного эталона
| Код | Функция |
| 0 | Не специфицирован или неизвестен |
| 1 | Калиброванные атомные часы (напр., hp 5061) |
| 2 | vlf (диапазон 4) или НЧ (диапазон 5) радио (напр., omega, wwvb) |
| 3 | ВЧ (диапазон 7) радио (напр., chu, msf, wwv/h) |
| 4 | УВЧ (диапазон 9) спутник (напр., goes, gps) |
| 5 | Локальная сеть (напр., dcn, tsp, dts) |
| 6 | UDP/NTP |
| 7 | UDP/time |
| 8 | eyeball-and-wristwatch |
| 9 | Телефонный модем (напр., nist) |
| 10-63 | Зарезервировано на будущее |
Код системного события - четырехбитовое число, идентифицирующее последнее системное событие, новое значение переписывает предыдущее. Коды событий перечислены в таблице 4.4.15.7.
Таблица 4.4.15.7. Коды системных событий
| Код | Функция |
| 0 | Не специфицировано |
| 1 | Рестарт системы |
| 2 | Системный или аппаратный сбой |
| 3 | Новое статусное слово системы (изменение битов добавления или синхронизации) |
| 4 | Новый источник синхронизации или слой (изменение sys.peer или sys.stratum) |
| 5 | Сброс системных часов (корректирующая добавка превысила clock.max) |
| 6 | Некорректное системное время или дата |
| 7 | system clock exception |
| 8-15 | Зарезервировано на будущее |
Статусное слово партнера возвращается в статусном поле отклика на команду чтения статуса, а также чтения или записи переменных. Это слово появляется в списке идентификаторов ассоциации и статусных слов, присылаемых в ответ на команду чтения статуса с нулевым идентификатором ассоциации. Формат статусного слова партнера содержит следующие поля (рис. 4.4.15.3)
Рис. 4.4.15.3. Форматы статусных слов
Статус партнера - 5-битный код, характеризующий состояние партнера, определяемого процедурой обмена. Значения этого поля представлены в таблице 4.4.15.8.
Таблица 4.4.15.8. Коды состояния партнера
| Значение кода | Функция |
| 0 | Сконфигурирован (peer.config) |
| 1 | Разрешена аутентификация (peer.authenable) |
| 2 | Аутентификация успешна (peer.authentic) |
| 3 | Партнер доступен (peer.reach) |
| 4 | Зарезервировано на будущее |
Таблица 4.4.15.9. Коды выбора партнера
| Значение кода | Функция |
| 0 | Отклонен |
| 1 | Проверка соответствия прошла успешно (тесты 1 - 8) |
| 2 | Прошел проверки корректности (алгоритм пересечения) |
| 3 | Прошел проверки, как кандидат |
| 4 | Проверка ресурсов прошла успешно (алгоритм кластеризации) |
| 5 | Текущий источник синхронизации; превышено максимальное расстояние (если используются предельные проверки) |
| 6 | Текущий источник синхронизации; максимальное расстояние в пределах нормы |
| 7 | Зарезервировано на будущее |
Код события партнера - 4-битовое целое число, идентифицирующее последнее событие партнера. Новое значение переписывает предыдущее. Значения кодов представлены в таблице 4.4.15.10.
Таблица 4.4.15.10. Коды события партнера
>
| Значение кода | Функция |
| 0 | Не специфицировано |
| 1 | IP-ошибка партнера |
| 2 | Ошибка аутентификации партнера (бит peer.authentic был равен 1, а теперь =0) |
| 3 | Партнер не достижим (peer.reach стал равен нулю) |
| 4 | Партнер достижим (peer.reach стал не равен нулю) |
| 5 | Проблема с часами партнера |
| 6-15 | Зарезервировано на будущее |
Существует два способа подключить эталонные часы к NTP-серверу, как специальный прибор, поддерживаемый операционной системой или как партнера, управляемого NTP. Как и в случае команды чтения статуса идентификатор ассоциации определяет, часы какого из партнеров имеются в виду. При нулевом идентификаторе речь идет о системных часах. Протокол поддерживает только одни системные часы, число часов-партнеров практически не ограничено. Статусное слово часов системы или партнера записывается в поле статуса отклика на команды чтения или записи переменных, характеризующих часы. Это слово может рассматриваться как расширение системного статусного слова или статусного слова партнера. Формат слова описан ниже (См. также рис. 4.4.15.3).
Состояние часов - 8-битовое число, характеризующее текущее состояние часов. Допустимые значения этого числа и их смысл представлены в таблице 4.4.15.11.
Таблица 4.4.15.11. Коды состояния часов
| Код | Функция |
| 0 | Работа часов в пределах нормы |
| 1 | Таймаут ответа |
| 2 | Плохой формат ответа |
| 3 | Сбой оборудования или программы |
| 4 | Потеря при передаче |
| 5 | Неверный формат или значение даты |
| 6 | Неверный формат или значение времени |
| 7-255 | Зарезервировано на будущее |
Слово состояния ошибки
Статусное слово ошибки присылается в поле статуса отклика, если обнаружена ошибка в формате сообщения или в его содержимом. Его присутствие указывается равенствами E (error) и R (response) битов 1. Коды ошибки и их значения собраны в таблице 4.4.15.12.
Таблица 4.4.15.12. Коды ошибки
Команды
Команды состоят из заголовка и опционного поля данных. Если поле данных присутствует, оно включает в себя список идентификаторов и, возможно, их значений.
[=],[=],...
где представляет собой имя переменной системы или партнера в форме ASCII-последовательности, а является десятичным или шестнадцатеричным числом, или строкой, соответствующей синтаксису языка C. Для большей читаемости допускается применение пробелов (Whitespace). IP-адреса представляются в формате [n.n.n.n], где n - десятичное число. Скобки являются опционными.
Команды интерпретируются следующим образом:
Чтение статуса (1). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Команда работает по-разному в зависимости от значения идентификатора. Если идентификатор не равен нулю, отклик содержит идентификатор партнера и статусное слово. Если идентификатор ассоциации равен нулю, отклик содержит системный идентификатор (0) и статусное слово, в то время как поле данных содержит список пар двоичных кодов:
,
по одному на каждую, определенную в данный момент ассоциацию.
Чтение переменных (2). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Если идентификатор ассоциации не равен нулю, отклик включает в себя идентификатор запрашиваемого партнера и его статусное слово, в то время как в поле данных записывается список переменных партнера и их значения. Если идентификатор ассоциации равен нулю, поле данных содержит список системных переменных и их значения. Если партнер выбран в качестве источника синхронизации, отклик включает в себя идентификатор партнера и его статусное слово.
Запись переменных (3). Поле данных команды содержит список присвоений, описанный выше. Отклик идентичен отклику на команду чтения переменных.
Чтение переменных часов (4). Поле данных команды пусто или содержит список идентификаторов, разделенных запятыми. Идентификатор ассоциации выбирает переменные системных часов или партнера точно также, как в случае команды чтения переменных. Отклик включает в себя запрошенные идентификатор часов и статусное слово, а поле данных несет в себе список переменных часов и их значений, включая последний временной код, полученный от часов.
Запись переменных часов (5). Поле данных команды содержит список присвоений, как это описано выше. Отклик имеет формат, как в случае команду чтения переменных часов.
Установка адреса/порта Trap (6). Идентификатор ассоциации команды, статус и поле данных игнорируются. Адрес и номер порта для последующих TRAP-сообщений берутся из самого управляющего сообщения. Исходное значение счетчика TRAP для сообщений откликов заимствуется из поля номера по порядку. Идентификатор ассоциации, статус и поле данных в отклике несущественны.
Отклик на TRAP (7). Это сообщение посылается, когда происходит событие (exception) в систему, у партнера или для данных часов. Код команды равен 7, а бит R=1. Содержимое trap-счетчика увеличивается на 1 для каждого сообщения данного типа. Поле номер по порядку сообщения равно содержимому этого счетчика. При посылке сообщения TRAP используется IP-адрес и номер порта, заданные командой установки адреса и порта TRAP. В случае системного TRAP идентификатор ассоциации устанавливается равным нулю, а поле статус содержит статусное слово системы. В случае TRAP партнера поле идентификатора ассоциации соответствует партнеру, а поле статус несет в себе его статусное слово. В поле данных опционно может быть включено любое символьное сообщение (ASCII).
Приложение В. Аутентификация
Требования надежности NTP подобны аналогичным для других протоколов, работающих с большим числом партнеров и служащих для маршрутизации, управления и доступа к файлам. Система должна противостоять случайным ошибкам и злонамеренным действиям.
Механизм управления доступом в NTP отвечает всем базовым требованиям. Различные проверки препятствуют большинству возможных атак, связанных с подменой временных меток.
Однако имеется возможность того, что хакер нарушит процедуру синхронизации путем модификации NTP-сообщений. Для подавления такой возможности нужно привлекать криптографические механизмы аутентификации (в частности сертификаты).
Механизм, который работает на прикладном уровне, служит для того, чтобы исключить неавторизованную модификацию потока сообщений. Это достигается с помощью контрольных крипто-сумм, вычисляемых отправителем и проверяемых получателем. Однако сам протокол NTP не имеет средств для работы с сертификатами и ключами.
Процедура вычисления контрольной крипто-суммы использует алгоритм DES (Data Encryption Standard) [NBS77].
Механизм аутентификации NTP
Когда предполагается использовать аутентификацию, инициализируется ряд переменных, определяющих выбор сертификата, алгоритма шифрования и крипто-ключ и, возможно, другие параметры. Процедуры инициализации и выбора этих переменных не регламентируются протоколом NTP. Набор переменных партнера и пакетов может включать в себя следующие компоненты:
Бит разрешения аутентификации (peer.authenable). Этот бит указывает, что ассоциация работает в режиме аутентификации. Для сконфигурированных партнеров этот бит определяется на фазе инициализации. Для неконфигурированных - этот бит делается равным 1, если приходящее сообщение содержит аутентификатор, в противном случае =0.
Бит аутентификации (peer.authentic). Этот бит указывает, что последнее сообщение, полученное от партнера, было корректно аутентифицировано.
Идентификатор ключа (peer.hostkeyid, peer.peerkeyid, pkt.keyid). Это целое число идентифицирует криптографический ключ, используемый для генерации кода аутентификации сообщения. Системная переменная peer.hostkeyid используется для активной ассоциации. Переменная peer.peerkeyid инициализируется нулем, когда ассоциация сформирована.
Криптографические ключи (sys.key). Это набор 64-битовых ключей DES, где 7 младших бит каждого октета соответствуют битам 1-7 DES, а старший бит соответствует биту четности 8 (сумма нечетна).
Контрольная крипто-сумма (pkt.check). Крипто-сумма вычисляется процедурой шифрования.
Поле аутентификатора состоит из двух субполей, одно содержит переменную pkt.keyid, а другое переменную pkt.check, вычисленную программой шифрования, вызываемой процедурой передачи протокола NTP, а также программой дешифровки, которая вызывается процедурой приема NTP. Ее присутствия определяется по общей длине UDP-дейтограммы. Для целей аутентификации NTP-сообщение дополняется нулями, для того чтобы сделать ее длину кратной 64 битам. Аутентификатор содержит 96 бит, куда входят 32-битовый идентификатор ключа и 64-битовая крипто-сумма. Дополнительная информация (например, о сертификате и алгоритме шифрования), если необходимо, может быть вставлена между NTP-сообщением и идентификатором ключа. Подобно аутентификатору эта информация не включается в контрольное крипто-суммирование.
Процедуры аутентификации NTP
Когда используется аутентификация для реализации протокола NTP, привлекается две дополнительные процедуры. Одна из них формирует крипто-сумму для передаваемых сообщений, а другая дешифрует и проверяет корректность контрольной суммы получаемых сообщений. Процедуры представляют собой варианты программ, используемых для реализации алгоритма DES и описанных в [NBS80]. На самом деле процедура не связана жестко с алгоритмом DES, а лишь предполагают работу с 64-битовыми блоками данных.
Приложение Г. Временная шкала NTP и ее хронометрия
Ниже рассматривается соответствие временной шкалы NTP и UTC (Coordinated Universal Time). Синхронизация часов предполагает их согласование по частоте и времени.
Для синхронизации необходимо уметь сравнить их частоты и показания. Базовыми источниками временных стандартов традиционно являлись периоды движения Земли, Луны и других космических объектов. К сожалению, они не слишком стабильны.
Первичная частота и стандарты времени
Первичными стандартами частоты являются осцилляторы с высокой стабильностью. Такие стандарты используют межуровневые переходы в атомах водорода, цезия и рубидия. В таблице 4.4.15.12 приведены характеристики типичных стандартов времени. Локальные же часы обычно используют некомпенсированные кварцевые генераторы. Такие генераторы не только подвержены дрейфам под действием изменения параметров окружающей среды, но систематически меняют свои свойства со временем (старение).
Даже если кварцевый генератор имеет температурную компенсацию, его частота должна время от времени сравниваться первичным стандартом для обеспечения высокой точности.
Сеть, в которой все часы фазированы и согласованы по частоте с единым стандартом, называется изохронной. Сети, где разные часы сфазированы с разными стандартами, но все они привязаны к одной базовой частоте называются плезиохронными. В плезиохронных системах фазы разных осцилляторов могут дрейфовать друг относительно друга, что может приводить к накоплению ошибок.
Обычно часовые осцилляторы классифицируются по трем параметрам: стабильность, разброс и блуждание. Стабильность определяется систематическими вариациями частоты со временем. Синонимом нестабильности является старение и дрейф. Разброс (называемый также временным дрожанием) характеризует кратковременные случайные вариации частоты с составляющими более 10 Гц, в то время как блуждание характеризует медленные вариации частоты с составляющими менее 10 Гц.
Таблица 4.4.15.12. Точность и стабильность часов для различных слоев
Конструкция, работа и характеристики осциллятора слоя 1 предполагаются сопоставимыми с национальными стандартами времени и часто базируются на цезиевом стандарте. Часы слоя 4 соответствуют требованиям обычных цифровых каналов и систем PBX. Слои 2-3 могут использоваться для работы с мощными синхронными каналами связи.
Раздача времени и частоты
Для того чтобы атомное и обычное время могли быть взаимосвязаны, национальные администрации обеспечивают работу первичных стандартов времени и частоты и совместно координируют их функционирование. Большинство морских держав поддерживают широковещательные радиослужбы времени.
Американский Национальный Институт Стандартов и Технологии (NIST – National Institute of Standards and Technology) поддерживает три радиослужбы для рассылки временной информации. Одна из них использует передачу (ВЧ или CCIR диапазон 7) на частотах 2.5, 5, 10, 15 и 20 Мгц. Сигнал распространяется, отражаясь от верхних слоев атмосферы, что неизбежно приводит к непредсказуемым вариациям задержки на принимающей стороне. С 60-секундным интервалом передается временной код, который транслируется на 100 килогерцной субнесущей со скоростью передачи 1 бит/с. Этот код содержит информацию об UTC времени и дате, но не включает в себя данных о текущем годе и оповещения о добавлении/вычитании секунды для последней минуты данного дня. Существуют и другие сходные службы времени (например, в Оттаве), гарантирующие точность на уровне 1-10 мсек.
Вторая служба времени NIST использует передачу (НЧ или CCIR диапазон 5) на частоте 60 КГц, она доступна на континентальной части США и вблизи берегов. Сигнал распространяется в нижней части атмосферы и по этой причине слабо подвержен вариациям времени распространения. Временной код передается с периодом в 60 секунд со скоростью 1 бит/с. Достижимая точность составляет 50 миллисекунд [BLA74]. Ряд европейских стран предлагают аналогичные службы времени (Великобритания - MSF; Германия - DCF77). Коды времени здесь включают информацию о текущем годе и предупреждение о добавляемой/вычитаемой секунде. Третья служба NIST использует передачу на частоте 468 МГц (УВЧ или CCIR диапазон 9) с геостационарных спутников GOES, три из которых перекрывают западное полушарие. Временной код перемежается с сообщениями, адресованными удаленным датчикам и состоит из 600 4-битовых слов, передаваемых с периодом в 30 секунд. Временной код содержит информацию об UTC времени-дне-годе, а также предупреждение о добавлении/вычитании секунды в конце дня. Точность этой службы составляет 0,5 мсек.
Министерство обороны США разработало глобальную систему определения координат GPS (Global Positioning System). Эта система базируется на 24 спутниках, движущихся по орбитам с периодом 12 часов. Система GPS может обеспечить точность определения времени на уровне нескольких наносекунд [VAN84].
Американская береговая охрана в течение многих лет использует службу радионавигации LORAN-C [FRA82]. Эта служба обеспечивает временную точность менее 1 мксек.
Система радионавигации военно-морского флота США и других стран OMEGA [VAS78] состоит из 8 передатчиков, работающих на частотах от 10.2 до 13.1 КГц (УНЧ или CIR диапазон 4) и перекрывающих весь земной шар 24 часа в сутки. Точность этой системы составляет около 1 мсек. Система OMEGA обеспечивает высокую точность для частоты, но не передает временного кода. По этой причине приемник должен предварительно получить географические координаты с точностью до градуса и время UTC с точностью 5 секунд от независимых источников.
Заметим, что не все службы времени передают информацию о текущем годе и предупреждения о добавлении/вычитании секунды. Протокол NTP позволяет решить эту проблему.
Определение частоты
В течение многих лет наиболее важным использованием времени и частоты были всемирная навигация и космическая наука, которые зависят от наблюдений солнца, луны и звезд. За стандартную секунду (в 1957 году) принята 1/31,556,925.9747 периода вращения Земли вокруг Солнца (тропический год). Согласно этой шкалы тропический год длится 365.2421987 дней, а лунный месяц 29.53059 дней. Однако тропический год может быть определен лишь с точностью около 50 мсек.
С древнейших времен человечеству были известны три осциллятора (процесса задающих временную шкалу) - вращение земли вокруг своей оси, вращение Луны вокруг Земли и вращение Земли вокруг Солнца. К сожалению, с точки требований современных технологий все эти три осциллятора не обладают достаточной стабильностью. В 1967 стандартная секунда была переопределена и теперь равняется 9,192,631,770 периодов перехода в атоме цезия-133. С 1972 стандарты времени и частоты базируются на международном атомном времени TAI (International Atomic Time). Точность таких часов составляет около микросекунды в сутки. Важно то, что новая шкала абсолютно однородна и не подвержена дрейфам.
Определение времени и необходимости добавления/вычитания секунды
Международное бюро мер и стандартов IBWM (International Bureau of Weights and Measures) использует астрономические наблюдения, выполненные морской обсерваторией США и другими обсерваториями для определения UTC.
Для более точной временной привязки событий после 1972 года необходимо знать, когда вставлялись или удалялись секунды коррекции (удаление пока никогда не производилось). Как определено в докладе 517 CCIR, который воспроизведен в [BLA74], дополнительные секунды вставляются после 23:59:59 в последний день июня или декабря. Неоднородность во временную шкалу (TAI) помимо добавляемых секунд вносят также 100 миллисекундные коррекции UT1, называемые DUT1, которые служат для повышения точности при навигации. Следует признать, что момент добавления секунды является началом новой (однородной) временной шкалы.
Временная шкала NTP базируется на шкале UTC, но необязательно всегда совпадает с ней. В 0 часов 1 января 1972 начинается эра UTC, часы NTP были установлены на 2,272,060,800 стандартных секунд после 0 часов 1 января 1900.
Ссылки
| [ABA89] | Abate, et al. AT&T's new approach to the synchronization of telecommunication networks. IEEE Communications Magazine (April 1989), 35-45. |
| [ALL74a] | Allan, D.W., J.H. Shoaf and D. Halford. Statistics of time and frequency data analysis. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 151-204. |
| [ALL74b] | Allan, D.W., J.E. Gray and H.E. Machlan. The National Bureau of Standards atomic time scale: generation, stability, accuracy and accessibility. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 205-231. |
| [BEL86] | Bell Communications Research. Digital Synchronization Network Plan. Technical Advisory TA-NPL-000436, 1 November 1986. |
| [BER87] | Bertsekas, D., and R. Gallager. Data Networks. Prentice-Hall, Englewood Cliffs, NJ, 1987. |
| [BLA74] | Blair, B.E. Time and frequency dissemination: an overview of principles and techniques. In: Blair, B.E. (Ed.). Time and Frequency Theory and Fundamentals. National Bureau of Standards Monograph 140, U.S. Department of Commerce, 1974, 233-314. |
| [BRA80] | Braun, W.B. Short term frequency effects in networks of coupled oscillators. IEEE Trans. Communications COM-28, 8 (August 1980), 1269-1275 |
| [COL88] | Cole, R., and C. Foxcroft. An experiment in clock synchronisation. The Computer Journal 31, 6 (1988), 496-502. |
| [DAR81a] | Defense Advanced Research Projects Agency. Internet Protocol. DARPA Network Working Group Report RFC-791, USC Information Sciences Institute, September 1981. |
| [DAR81b] | Defense Advanced Research Projects Agency. Internet Control Message Protocol. DARPA Network Working Group Report RFC-792, USC Information Sciences Institute, September 1981. |
| [DEC89] | Digital Time Service Functional Specification Version T.1.0.5. Digital Equipment Corporation, 1989 |
| [DER90] | Dershowitz, N., and E.M. Reingold. Calendrical Calculations. Software Practice and Experience 20, 9 (September 1990), 899-928. |
| [FRA82] | Frank, R.L. History of LORAN-C. Navigation 29, 1 (Spring 1982). |
| [GUS84] | Gusella, R., and S. Zatti. TEMPO - A network time controller for a distributed Berkeley UNIX system. IEEE Distributed Processing Technical Committee Newsletter 6, NoSI-2 (June 1984), 7-15. Also in: Proc. Summer USENIX Conference (June 1984, Salt Lake City). |
| [GUS85a] | Gusella, R., and S. Zatti. The Berkeley UNIX 4.3BSD time synchronization protocol: protocol specification. Technical Report UCB/CSD 85/250, University of California, Berkeley, June 1985. |
| [GUS85b] | Gusella, R., and S. Zatti. An election algorithm for a distributed clock synchronization program. Technical Report UCB/CSD 86/275, University of California, Berkeley, December 1985. |
| [HAL84] | Halpern, J.Y., B. Simons, R. Strong and D. Dolly. Fault-tolerant clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 89-102. |
| [JOR85] | Jordan, E.C. (Ed). Reference Data for Engineers, Seventh Edition. H.W. Sams & Co., New York, 1985. |
| [KOP87] | Kopetz, H., and W. Ochsenreiter. Clock synchronization in distributed real-time systems. IEEE Trans. Computers C-36, 8 (August 1987), 933-939. |
| [LAM78] | Lamport, L., Time, clocks and the ordering of events in a distributed system. Comm. ACM 21, 7 (July 1978), 558-565. |
| [LAM85] | Lamport, L., and P.M. Melliar-Smith. Synchronizing clocks in the presence of faults. J. ACM 32, 1 (January 1985), 52-78. |
| [LIN80] | Lindsay, W.C., and A.V. Kantak. Network synchronization of random signals. IEEE Trans. Communications COM-28, 8 (August 1980), 1260-1266. |
| [LUN84] | Lundelius, J., and N.A. Lynch. A new fault-tolerant algorithm for clock synchronization. Proc. Third Annual ACM Symposium on Principles of Distributed Computing (August 1984), 75-88. |
| [MAR85] | Marzullo, K., and S. Owicki. Maintaining the time in a distributed system. ACM Operating Systems Review 19, 3 (July 1985), 44-54. |
| [MIL81a] | Mills, D.L. Time Synchronization in DCNET Hosts. DARPA Internet Project Report IEN-173, COMSAT Laboratories, February 1981. |
| [MIL81b] | Mills, D.L. DCNET Internet Clock Service. DARPA Network Working Group Report RFC-778, COMSAT Laboratories, April 1981. |
| [MIL83a] | Mills, D.L. Internet Delay Experiments. DARPA Network Working Group Report RFC-889, M/A-COM Linkabit, December 1983. |
| [MIL83b] | Mills, D.L. DCN local-network protocols. DARPA Network Working Group Report RFC-891, M/A-COM Linkabit, December 1983. |
| [MIL85a] | Mills, D.L. Algorithms for synchronizing network clocks. DARPA Network Working Group Report RFC-956, M/A-COM Linkabit, September 1985. |
| [MIL85b] | Mills, D.L. Experiments in network clock synchronization. DARPA Network Working Group Report RFC-957, M/A-COM Linkabit, September 1985. |
| [MIL85c] | Mills, D.L. Network Time Protocol (NTP). DARPA Network Working Group Report RFC-958, M/A-COM Linkabit, September 1985. |
| [MIL88a] | Mills, D.L. Network Time Protocol (version 1) - specification and implementation. DARPA Network Working Group Report RFC-1059, University of Delaware, July 1988. |
| [MIL88b] | Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo Alto, CA, August 1988), 115-122. |
| [MIL89] | Mills, D.L. Network Time Protocol (version 2) - specification and implementation. DARPA Network Working Group Report RFC-1119, University of Delaware, September 1989. |
| [MIL90] | Mills, D.L. Measured performance of the Network Time Protocol in the Internet system. ACM Computer Communication Review 20, 1 (January 1990), 65-75. |
| [MIL91a] | Mills, D.L. Internet time synchronization: the Network Time Protocol. IEEE Trans. Communications 39, 10 (October 1991), 1482-1493. |
| [MIL91b] | Mills, D.L. On the chronology and metrology of computer network timescales and their application to the Network Time Protocol. ACM Computer Communications Review 21, 5 (October 1991), 8-17. |
| [MIT80] | Mitra, D. Network synchronization: analysis of a hybrid of master-slave and mutual synchronization. IEEE Trans. Communications COM-28, 8 (August 1980), 1245-1259. |
| [NBS77] | Data Encryption Standard. Federal Information Processing Standards Publication 46. National Bureau of Standards, U.S. Department of Commerce, 1977. |
| [NBS79] | Time and Frequency Dissemination Services. NBS Special Publication 432, U.S. Department of Commerce, 1979 |
| [NBS80] | DES Modes of Operation. Federal Information Processing Standards Publication 81. National Bureau of Standards, U.S. Department of Commerce, December 1980. |
| [POS80] | Postel, J. User Datagram Protocol. DARPA Network Working Group Report RFC-768, USC Information Sciences Institute, August 1980. |
| [POS83a] | Postel, J. Daytime protocol. DARPA Network Working Group Report RFC-867, USC Information Sciences Institute, May 1983. |
| [POS83b] | Postel, J. Time protocol. DARPA Network Working Group Report RFC-868, USC Information Sciences Institute, May 1983. |
| [RIC88] | Rickert, N.W. Non Byzantine clock synchronization - a programming experiment. ACM Operating Systems Review 22, 1 (January 1988), 73-78. |
| [SCH86] | Schneider, F.B. A paradigm for reliable clock synchronization. Department of Computer Science Technical Report TR 86-735, Cornell University, February 1986. |
| [SMI86] | Smith, J. Modern Communications Circuits. McGraw-Hill, New York, NY, 1986. |
| [SRI87] | Srikanth, T.K., and S. Toueg. Optimal clock synchronization. J. ACM 34, 3 (July 1987), 626-645. |
| [STE88] | Steiner, J.G., C. Neuman, and J.I. Schiller. Kerberos: an authentication service for open network systems. Proc. Winter USENIX Conference (February 1988). |
| [SU81] | Su, Z. A specification of the Internet protocol (IP) timestamp option. DARPA Network Working Group Report RFC-781. SRI International, May 1981. |
| [TRI86] | Tripathi, S.K., and S.H. Chang. ETempo: a clock synchronization algorithm for hierarchical LANs - implementation and measurements. Systems Research Center Technical Report TR-86-48, University of Maryland, 1986. |
| [VAN84] | Van Dierendonck, A.J., and W.C. Melton. Applications of time transfer using NAVSTAR GPS. In: Global Positioning System, Papers Published in Navigation, Vol. II, Institute of Navigation, Washington, DC, 1984. |
| [VAS78] | Vass, E.R. OMEGA navigation system: present status and plans 1977-1980. Navigation 25, 1 (Spring 1978). |
Сетевые драйверы
7.2 Сетевые драйверы
Семенов Ю.А. (ГНЦ ИТЭФ)
NE2000 0x60 0x5 0x300
, (если ваша ЭВМ снабжена интерфейсом типа NE2000).
Здесь предполагается, что интерфейс будет использовать номер прерывания 0x60, аппаратное прерывание 0x5 и блок портов, начиная с шестнадцатеричного адреса 0x300 (io_addr). Следует иметь в виду, что разные интерфейсы могут иметь разное число CSR-регистров и отличные от приведенных ниже функции (NE2100). Интерфейс характеризуется тремя целыми числами: класс (8 бит), тип (16 бит) и номер. Класс говорит о том, для какой из сетевых сред предназначен данный прибор (PPP, DIX Ethernet, IEEE 802.3, IEEE 802.5, Pronet-10, Appletalk и т.д.). Тип описывает конкретную реализацию интерфейса (NE2000, NI5210, 3C501 и т.д.). Тип 0xffff соответствует всем интерфейсам данного класса. В случае, когда ЭВМ оснащена более чем одним интерфейсом идентичного типа, для их идентификации используется номер. На рис. 7.2.1 показана структура управляющего (CSR) регистра сетевого интерфейса. В таблице 7.2.1 приведен перечень основных классов с примерами определенных типов интерфейсов.
Рис. 7.2.1.А Структура CSR-регистра интерфейса (CSR0)
Рис. 7.2.1.Б. CSR1
CSR2 (доступ разрешен при CSR0[stop] = 1)
Рис. 7.2.1В. CSR2
| Bcon | 0 = <0:7> перестановка байтов адресов |
| Acon | 0 = ale, 1 = /as |
| Bswp | 0 = /bm1, bm0, /hold; |
Рис. 7.2.1.Г. CSR3
Таблица 7.2.1.
| Сетевая среда | Класс | Фирма, интерфейс | Тип интерфейса |
| dec/intel/Xerox | 1 | 3com 3C500/3C501 | 1 |
| "Bluebook" ethernet | 3com 3C505 | 2 | |
| Interlan NI5010 | 3 | ||
| Micom-Interlan NP600 | 6 | ||
| Ungermann-bass PC-nic | 8 | ||
| Univation NC-516 | 9 | ||
| TRW PC-2000 | 10 | ||
| Interlan NI5210 | 11 | ||
| 3com 3C503 | 12 | ||
| 3com 3C523 | 13 | ||
| Western digital WD8003 | 14 | ||
| Spider systems S4 | 15 | ||
| Torus frame level | 16 | ||
| 10net communications | 17 | ||
| Gateway PC-bus | 18 | ||
| Gateway at-bus | 19 | ||
| Gateway MCA-bus | 20 | ||
| IMC PCnic | 21 | ||
| 1 | IMC PCnic II | 22 | |
| Micromatic research | 25 | ||
| Clarkson "multiplexor" | 26 | ||
| D-link 16-bit | 28 | ||
| D-link ps/2 | 29 | ||
| Research machines 16 | 31 | ||
| Research machines MCA | 32 | ||
| Interlan NI9210 | 34 | ||
| Interlan NI6510 | 35 | ||
| Novell NE2000 | 36 | ||
| Allied telesis pc/xt/at | 38 | ||
| Allied telesis NEC PC-98 | 39 | ||
| Ungermann-bass NIC/PS2 | 41 | ||
| Tiara lancard/E AT | 42 | ||
| Tiara Lancard/E MC | 43 | ||
| Tiara Lancard/E TP | 44 | ||
| AT&T Starlan NAU | 47 | ||
| AT&T Starlan-10 NAU | 48 | ||
| AT&T Ethernet NAU | 49 | ||
| Pronet-10 | 2 | Proteon P1300 | 1 |
| Proteon P1800 | 2 | ||
|
IEEE 802.5/pronet-4 IBM Token Ring интерфейс |
3 | Proteon P1340 | 2 |
| Proteon P1344 | 3 | ||
| Gateway PC-bus | 4 | ||
| Gateway AT-bus | 5 | ||
| Gateway MCA-bus | 6 | ||
| Omninet | 4 | ||
| Appletalk | 5 | ||
| Последовательный интерфейс | 6 | Clarkson 8250-slip | 1 |
| Clarkson "multiplexor" | 2 | ||
| Starlan | 7 | ||
| Arcnet | 8 | Datapoint RIM | 1 |
| AX.25 | 9 | ||
| KISS | 10 | ||
| IEEE 802.3 w/802.2 HDRS | 11 | ||
| FDDI W/802.2 HDRS | 12 | ||
| Internet X.25 | 13 | Western Digital | 1 |
| N.T. Lanstar (encap. dix) | 14 | NT Lanstar/8 | 1 |
| NT Lanstar/mc | 2 | ||
| SLFP | 15 | ||
| Netrom | 16 | ||
| Nclass | 17 |
/p> Любой пакетный драйвер имеет блок исходных данных (MS-DOS), напр.:
| EADDR_LEN | equ 6 | ; длина физического адреса | |
| init_block | struc | ||
| init_mode | dw | 0 | |
| init_addr | db | eaddr_len dup(?) | ; ethernet-адрес |
| init_filter | db | 8 dup(0) | ; Логический адресный фильтр (multicast filter). |
| init_receive | dw | ?,? | ; Указатель входного кольцевого буфера |
| init_transmit | dw | ?,? | ; Указатель выходного кольцевого буфера. |
| init_block | ends |
Рис. 7.2.2. Структура переменных init_mode
| Drx | запрет приема; |
| Dtx | запрет передачи; |
| Loop | цикл; |
| Dtcr | запрет передачи crc; |
| Coll | столкновение; |
| Drty | запрет повторов; |
| Intl | внутренний цикл; |
| Prom | режим приема всех пакетов (promiscuous mode). |
| rcv_msg_dscp | struc | |
| rd_addr | dw ? | ; Младшая часть адреса входного буфера |
| rd_stat | dw ? | ; Статусная часть + старшая часть адреса |
| rd_bcnt | dw ? | ; Размер буфера в байтах |
| rd_mcnt | dw ? | ; Длина сообщения в байтах |
| rcv_msg_dscp | ends |
Рис. 7.2.3. Структура переменных rd_stat
| Enp | конец пакета; |
| Stp | начало пакета; |
| Buff | ошибка в буфере; |
| CRC | CRC-ошибка; |
| Oflo | переполнение буфера; |
| Fram | ошибка при записи в буфер; |
| Err | наличие ошибки; |
| Own | 0 = полное заполнение. |
Я не буду описывать здесь то, как следует писать системные драйверы (Исчерпывающую информацию по написанию таких драйверов читатель может найти в книге "Написание драйверов для MS-DOS" Р.Лея и "Уэйт Груп", Москва "Мир", 1995), тем более что существует достаточное их количество в депозитариях общего доступа (Например, анонимное FTP по адресам ftp.funet.fi, ftp.switch.ch или oak.oakland.edu, депозитарий SimTel ). Приведенное выше описание регистров интерфейса не является единственно возможным (см. также руководство по сетевому контроллеру 8390 и файл NE2.ASM из ссылки ftp.funet.fi. Структура драйверов варьируется для разных операционных систем. Для системных программистов полезно иметь возможность настраивать драйвер или непосредственно интерфейс на определенный режим, например, на прием всех пакетов, проходящих по кабельному сегменту. Последнее может представлять интерес в диагностических целях, так как вслед за пакетным драйвером загружается Etherdrv, Winsock или winpkt и т.д., блокирующие режим приема всех пакетов (mode=6). Ниже приведен пример описания основных параметров драйвера:
| BLUEBOOK | equ | 1 | |
| IEEE8023 | equ | 11 | |
| ADDR_LEN | equ | 6 | ; размер Ethernet-адреса |
| MAX_M_CAST | equ | 8 | ; максимальное число мультикаст-адресов. |
/p>
| Public | int_no, | io_addr | |
| int_no | db | 2,0,0,0 | ; должно иметь 4 байта для get_number. |
| io_addr | dw | 0300h,0 | ; I/O адрес карты (переключатели) |
| public | driver_class | driver_type, | driver_name, | driver_function, | parameter_list |
| driver_class | db | BLUEBOOK, IEEE8023, 0 | ; из спецификации интерфейса | ||
| driver_type | dw | 54 | ; из спецификации интерфейса | ||
| driver_name | db | 'NE2000',0 | ; имя драйвера. | ||
| driver_function | db | 2 | |||
| parameter_list | label | byte | |||
| db | 1 | ; | |||
| db | 9 | ; | |||
| db | 14 | ; длина списка параметров в байтах | |||
| db | ADDR_LEN | ; длина адреса MAC-уровня в байтах | |||
| dw | GIANT | ; MTU, включая MAC-заголовок | |||
| dw | MAX_M_CAST * ADDR_LEN |
| dw | 0 | ;(# принимаемых подряд пакетов с; размером MTU) - 1 | |
| dw | 0 | ; (# посылаемых подряд пакетов) - 1 | |
| int_num | dw | 0 | ; Номер прерывания |
Существует множество пакетных драйверов. Можно обнаружить несколько модификаций для одного и того же типа интерфейса. Эти драйверы могут быть ориентированы на работу в разных программных средах (Novell, UNIX, MS-DOS и т.д.) и иметь разные возможности. Для MS-DOS сложился неофициальный стандарт, который позволяет использовать драйвер для самых разных приложений. Драйвер может использовать минимум возможностей интерфейса (базовый уровень), реализовать более широкий набор функций (мультикастинг, сбор статистики и т.д.) или поддерживать практически все, на что способен данный прибор. В последнем случае он занимает больше места в памяти. Описания операций с пакетными драйверами, приведенные ниже, выполнены в нотации ассемблера IBM/PC. При написании программы следует помнить, что порядок байтов в Ethernet противоположен тому, который используется в вашей IBM/PC.
Пакетные драйверы используют программные прерывания в интервале 0x60 - 0x80. Следует сразу заметить, что не все прерывания из этого списка свободны и при конфигурировании системы следует проявлять осмотрительность. Для того чтобы избежать конфликтов с другими внешними устройствами, предусматривается возможность реконфигурации прерываний. Предполагается, что программа обработки прерываний начинается с команды безусловной передачи управления (JMP), за которой следует текстовая строка "PKT DRVR". Именно эта строка служит указателем при поиске адреса пакетного прерывания. Практически все драйверы могут работать с различными протоколами (TCP/IP, OSI и др.). Решить задачу мультиплексирования на связном уровне помогает процедура access_type, которая обеспечивает доступ для пакетов определенного типа.
Все функции реализуются с помощью обращения к драйверу с набором определенных параметров. При этом значение регистра AH определяет тип запроса. Каждому типу используемого сетевого протокола, с которым работает интерфейс, ставится в соответствие целочисленный указатель (handle), получаемый с помощью процедуры access_type. Выполнимость драйвером тех или иных операций может быть выяснена с помощью запроса driver_info.
При работе с драйвером следует проявлять осторожность и спасать нужные вам регистры. Следует также помнить, что порядок байтов в PC и в некоторых сетях, включая Ethernet, не совпадает. Описание основных запросов, посылаемых пакетному драйверу:
1. Получение информации о типе и функциональных возможностях драйвера
driver_info AH == 1,
AL == 255 (код запроса)
| BX | версия; |
| CH | класс; |
| CL | номер; |
| DX | тип; |
| DS:SI | указывают на строку имени драйвера; |
| AL | функциональные возможности. |
| AL = 1 | гарантируется выполнение базовых функций; |
| = 2 | обеспечено выполнение базового и расширенного набора функций; |
| = 5 | выполняется базовый и экстра-набор функций; |
| = 6 | выполним полный набор функций; |
| = 255 | драйвер не установлен. |
/p> Ниже приведен пример программы, реализующей некоторые из описанных запросов.
| .MODEL | small | |
| PUBLIC | _INFACE | |
| VERSION | EQU | 1 |
| EXTRN | _PARAM:BYTE | |
| EXTRN | _Q:BYTE |
| INCLUDE | DEF.ASM | ; Определения некоторых констант | |
| P_LIST | STRUC | ||
| LINTN | DB | 32 dup(0) | ; Список активных номеров прерываний |
| HANDLES | DW | ? | |
| HANDLEP | DW | ? | |
| ER_CODE | DW | ? | |
| ERNUM | DW | ? | ; Код ошибки |
| HANDLER | DD | ? | |
| MODE | DW | ? | ; Текущий режим приема пакетов |
| MLIST | DB | 0,0,0,0,0,0 | ; Список допустимых режимов; 1 => имеется |
| PKT_IN | DW | ?,? | ; Диагностический массив |
| pkt_out | DW | ?,? | |
| byte_in | DW | ?,? | |
| byt_out | DW | ?,? | |
| err_in | DW | ?,? | |
| err_out | DW | ?,? | |
| pk_drop | DW | ?,? | |
| L1 | DW | 0 | ; Версия драйвера |
| L2 | DW | 0 | ; класс/номер |
| L3 | DW | 0 | ; Тип |
| L4 | DW | 0 | ; Функция |
| _NAME | DB | 0,0,0,0,0,0,0,0,0,0 | ; Имя интерфейса |
| ETHER_ADR | DB | ADDR_LEN dup(-1) | ; Ethernet-адрес |
| S_ADR | DB | EADDR_LEN+5 dup(-1) | ; Ethernet-адрес получателя |
| D_ADR | DB | EADDR_LEN+5 dup(-1) | ; Ethernet-адрес отправителя |
| P_LIST | ENDS |
| QUEUE | STRUC | ||
| Leng | DW | 15000,? | ; Длина очереди |
| Tail | DW | ? | ; Смещение последнего элемента очереди |
| Head | DW | ? | ; Смещение первого элемента очереди |
| _end | DW | ? | ; Указатель на конец очереди |
| p_len | DW | ? | ; Длина пакета |
| P_start | DW | ? | ; Указатель на текущий пакет = Q_head - Q_begin +2 |
| NEW | DB | 0 | ; Флаг нового пакета |
| Line | DB | ? | ; Строка экрана |
| Npacks | DD | 0 | ; Счетчик принятых пакетов |
| B | DW | ? | ; смещение Q_beg |
| Point | DW | 380 dup(?) | |
| Beg | DB | 31000 dup(?) | ; Пакетный буфер |
| QUEUE | ENDS |
| ether_bdcst | DB | EADDR_LEN dup(-1) | ; Широковещательный адрес Ethernet, заполненный -1. |
| ether_addr | DB | EADDR_LEN dup(-1) | |
| bogus_type | DB | 0,0; | |
| signature | DB | 'PKT DRVR',0 | ; Сигнатура пакетного драйвера |
| signature_len | equ | $-signature | |
| SAFE | DW | ? | |
| DFLAG | DB | 0 |
/p> .CODE
| PUBLIC | _INFACE | |
| _INFACE | PROC | NEAR |
| CLD | ||
| MOV DFLAG, 0 | ; Очистка флага драйвера | |
| MOV _PARAM.ER_CODE, 0 | ; Очистка флага ошибки | |
| PUSH BP | ; Спасение регистров | |
| MOV BP, SP | ||
| PUSH SI | ||
| PUSH DI | ||
| PUSH ES | ||
| PUSH DS |
| MOV CX, 32 | ||
| MOV AL, 60H | ; Установка начального номера прерывания | |
| LEA SI, _PARAM.LINTN | ; Формирование указателя на список номеров прерывания | |
| CHECK: | PUSH AX | |
| PUSH CX | ||
| PUSH SI | ||
| CALL CHK_INT | ||
| POP SI | ||
| POP CX | ||
| MOV byte ptr [SI], 0 ; | ||
| JNE NO_SIGNATURE | ||
| INC DFLAG | ; Установка флага <Это драйвер> | |
| MOV BYTE PTR [SI], 1 | ; Установка флага наличия |
| POP AX | ||
| INC AL | ; Следующий номер прерывания | |
| INC SI | ; Актуализация указателя | |
| LOOP CHECK |
| CMP DFLAG, 0 | ; Драйвер присутствует? | |
| JNE HAVE_SIGNATURE | ||
| MOV _PARAM.ER_CODE, 271 | ; Установка флага <No signature> | |
| JMP OKAY |
| PUSH ES | |
| pushf | |
| cli | |
| call _PARAM.HANDLER | |
| POP ES | |
| RET |
| CHK_INT: | PUSH ES | ; AL = номер прерывания |
| PUSH DI |
| MOV AH, 35H | ; Получение вектора прерывания | |
| INT 21H | ; ES:BX=seg:offs драйвера |
| MOV _PARAM.HANDLER.OFFS,BX | ; Записываем адрес драйвера | |
| MOV _PARAM.HANDLER.SEGM, ES | ||
| LEA DI, 3[BX] | ; Устанавливаем смещение сигнатуры драйвера | |
| MOV SI, OFFSET SIGNATURE | ; Проверка сигнатуры драйвера | |
| MOV CX, SIGNATURE_LEN | ; Присутствует ли здесь драйвер? | |
| REPE CMPSB ; DS:[SI] - ES:[DI] |
/p>
| POP DI | |
| POP ES | |
| RET |
| MOV CX, 32 | ; Установка начального значения счетчика | |
| LEA SI, _PARAM.LINTN | ; Устанавливаем указатель списка | |
| MOV AL, 60H | ; Задаем начальный номер прерывания | |
| CHOICE: | CMP BYTE PTR [SI], 0 | |
| JNE SETDRV | ||
| INC AL | ||
| LOOP CHOICE |
| SETDRV: | MOV AH, 35H | |
| INT 21H | ||
| MOV _PARAM.HANDLER.OFFS,BX | ; Определяем адрес драйвера | |
| MOV _PARAM.HANDLER.SEGM, ES |
| PUSH DS | ||
| POP ES | ||
| MOV CX, EADDR_LEN | ||
| MOV SI, OFFSET ETHER_ADDR | ||
| MOV DI, OFFSET ETHER_BDCST | ||
| REPE CMPSB | ||
| JE GET_MODE | ; Адрес не определен |
| MOV AH, 25 | ; Записываем ethernet-адрес | |
| MOV DI, offset ETHER_ADDR | ||
| MOV CX, EADDR_LEN | ||
| call int_pkt | ||
| MOV _PARAM.ER_CODE, DX | ; Устанавливаем код ошибки | |
| JMP OKAY |
| MOV SAFE, DS | ; Спасаем DS | |
| PUSH DS | ||
| MOV AH, 2 | ; Открываем доступ пакетам | |
| MOV AL, 1 | ; Класс интерфейса | |
| MOV BX, -1 | ; Тип интерфейса | |
| MOV DL, 0 | ; Номер интерфейса | |
| MOV CX, 2 | ; Используем длину type = 2 | |
| MOV SI, OFFSET BOGUS_TYPE | ||
| PUSH CS | ; ES:DI -> Receiver. | |
| POP ES | ||
| MOV DI, OFFSET RECEIVER | ||
| call INT_PKT | ||
| JNC $_$ | ||
| MOV _PARAM.ER_CODE, DX | ; Устанавливаем код ошибки | |
| $_$: | MOV _PARAM.HANDLES, AX | ; Записываем указатель-Handle |
| MOV AH, 6 | ; Определяем ethernet-адрес интерфейса | |
| PUSH DS | ||
| POP ES | ||
| MOV DI, offset _PARAM.ETHER_ADR | ||
| MOV CX, EADDR_LEN | ||
| MOV BX, _PARAM.HANDLES | ||
| call int_pkt | ||
| JNC NOBAD | ||
| MOV _PARAM.ER_CODE, 273 | ; Ошибка при определении Ethernet-адреса | |
| POP DS | ||
| JMP OKAY |
/p> NOBAD:
| MOV AX, 1FFH | ; Запрашиваем информацию о драйвере | |
| MOV BX, _PARAM.HANDLES | ; Устанавливаем указатель | |
| call INT_PKT | ||
| JNC N_BAD | ||
| MOV _PARAM.ER_CODE, 272 | ; Ошибка при получении информации о драйвере | |
| POP DS | ||
| JMP OKAY |
| N_BAD: | PUSH DS |
| PUSH SS | |
| &nsp; | POP DS |
| MOV ES, SAFE |
| MOV _PARAM.L1, BX | ; Версия драйвера | |
| MOV _PARAM.L2, CX | ; номер/класс | |
| MOV _PARAM.L3, DX | ; Тип | |
| MOV _PARAM.L4, AX | ; Функциональность | |
| LEA BX, _PARAM._NAME | ||
| POP DS | ||
| MOV CX, 8 | ||
| ZFIND: | CMP byte ptr [SI], 0 | |
| MOV AL, byte ptr [SI] | ||
| MOV byte ptr ES:[BX], AL | ||
| JE ZERO_ | ||
| INC SI | ||
| INC BX | ||
| LOOP ZFIND | ||
| ZERO_: | POP DS | |
| MOV AH, 21 | ; Запрашиваем код режима приема пакетов | |
| MOV BX, _PARAM.HANDLES | ||
| call INT_PKT | ||
| MOV _PARAM.MODE, AX | ; Записываем код режима |
| OKAY: | POP DS |
| POP ES | |
| POP DI | |
| POP SI | |
| MOV SP, BP | |
| POP BP | |
| RET |
| RECEIVER: | ; Подпрограмма RECEIVER, вызываемая при получении пакета | |
| OR AX, AX | ; Первый или второй вызов? | |
| JNE RECV | ||
| MOV AX, seg _Q.beg | ; Указатель буфера ES:DI | |
| MOV ES, AX | ||
| MOV DI, offset _Q.beg |
| RECV: | RETF |
access_type(if_class, if_type, if_number, type, typelen, receiver)
AH ==2 (код запроса)
Запрос access_type инициализирует доступ для пакетов определенного типа (type). Аргумент typelen – длина спецификации типа в байтах, для PC/TCP равна 5 (наименьшее значение - 2, для IP и ARP). Аргумент receiver является указателем на подпрограмму, которая вызывается при приеме пакета. Получая пакет, драйвер дважды обращается к этой программе. Первый раз (при AX==0) это делается с целью получения адреса буфера, куда должен быть положен пакет. Прикладная программа в этом случае должна выдать указатель буфера в регистры ES:DI. Если прикладной процесс не имеет свободного буфера,то возвращается значение 0:0. Пакет выбрасывается и повторное обращение к программе receiver отменяется. Форма реализации запроса аналогична приведенному для driver_info:
| Int | if_class; AL | ; класс интерфейса |
| Int | if_type; BX | ; тип интерфейса |
| Int | if_number; DL | ; номер интерфейса |
| Char | far *type; DS:SI | |
| Unsigned | typelen; CX | |
| Int | (far *receiver); ES:DI |
/p>
| access: | mov ah, 2 | |
| mov al, ch | ; установка класса; здесь предполагается, что содержимое регистров соответствует тому, что получено в результате обращения к driver_info | |
| mov bx, dx | ; устанавливаем параметр type | |
| mov dl, cl | ; устанавливаем параметр number, при одном интерфейсе number=0 | |
| xor cx, cx | ; длина type равна нулю | |
| push cs | ; устанавливаем сегментный регистр receiver | |
| pop es | ||
| mov di, offset RECEIVER | ; вызов подпрограммы receiver | |
| call int_pkt | ; обращение к пакетному драйверу |
| 2 | NO_CLASS не найдено интерфейса указанного класса; |
| 3 | NO_TYPE не найдено интерфейса указанного типа; |
| 4 | NO_NUMBER не найдено интерфейса с указанным номером; |
| 5 | BAD_TYPE специфицирован неправильный тип пакета; |
| 9 | NO_SPACE недостаточно места в памяти; |
| 10 | TYPE_INUSE было обращение к данному типу и он пока занят. |
Обращение к приемнику (receiver):
(*receiver)(handle, flag, len [, buffer])
| int handle; | BX | ; указатель |
| int flag; | AX | ; флаг вызова(0/1) |
| unsigned len; | CX | ; целое без знака - длина пакета |
| char far *buffer; | DS:SI | ; адрес буфера |
3. Завершение доступа пакетов данного типа release_type
int release_type(handle) AH == 3;
код запроса int handle;
BX ; указатель определяет тип пакетов
_release_type proc near
| push bp | ; спасение регистров | |
| push ds | ||
| push es | ||
| mov ah, 3 | ; задаем код запроса | |
| mov bx, _param.handle | ; заносим указатель | |
| pushf | ||
| cli | ||
| call _param.handler | ; обращение к драйверу | |
| mov _param.er_CODE, dx | ; занесение кода ошибки | |
| pop es | ; восстановление регистров | |
| pop ds | ||
| pop bp | ||
| ret | ||
| _release_type | endp |
4. Процедура посылки пакета send_packet(buffer, length)
AH == 4 (код запроса)
char far *buffer; DS:SI (адрес буфера)
unsigned length; CX (длина пакета в байтах)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 12 CANT_SEND. send_packet отправляет пакет с числом байт, равным CX. Пакет должен в исходный момент лежать, начиная с адреса DS:SI. Прикладная программа должна сформировать все необходимые заголовки. Информация, нужная для осуществления демультиплексирования пакетов (MAC или LLC), также должна быть записана в пакет, так как при этом запросе не сообщается значение указателя (handle).
5. Завершение работы драйвера terminate(handle)
AH == 5 (код запроса)
int handle; BX (указатель)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
1 BAD_HANDLE;
7 CANT_TERMINATE.
Завершает работу драйвера, соответствующего указателю, который приведен в качестве параметра запроса. Если возможно, драйвер будет выгружен и занимаемая им память освобождена.
6. Получение физического адреса интерфейса get_address(handle,buf,len)
AH == 6 (код запроса)
int handle; BX (указатель)
char far *buf; ES:DI (адрес буфера)
int len; CX (длина адреса в байтах)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
1 BAD_HANDLE;
9 NO_SPACE. При успешном выполнении запроса флаг carry=0, а в регистр CX занесена длина адреса.
Копирует текущее значение сетевого (физического) адреса интерфейса в буфер. Если получено сообщение NO_SPACE, это означает, что выделенного места (len=CX) для копирования адреса не хватило.
7. Возвращение интерфейса в исходное состояние reset_interface(handle)
AH == 7 (код запроса)
int handle; BX (указатель)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
1 BAD_HANDLE;
15 CANT_RESET.
Возвращает интерфейс в исходное состояние, прерывая все процессы. Местное значение физического сетевого адреса, если оно было изменено, восстанавливается из ROM, прием переключается в режим 3, а список мультикастинг-адресов обнуляется. При работе с несколькими указателями (handle) возможны серьезные неприятности, по этому выполнение запроса блокируется и присылается сообщение CANT_RESET.
8. Запрос установки режима приема пакетов set_rcv_mode(handle,mode)
AH == 20 (код запроса) int handle;
BX (входные параметры - указатель) int mode;
CX (код режима приема пакетов)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
1 BAD_HANDLE;
8 BAD_MODE.
Устанавливает режим приема пакетов. Режим 3 используется по умолчанию. Возможны (но не для всех интерфейсов) следующие режимы:
| Режим | Значение |
| 1 | выключение приема пакетов; |
| 2 | прием пакетов, адресованных только данному интерфейсу; |
| 3 | режим 2 плюс бродкастинг-пакеты; |
| 4 | режим 3 плюс некоторые мультикастинг-пакеты; |
| 5 | режим 3 плюс все мультикастинг-пакеты; |
| 6 | все пакеты. |
AH == 21 (код запроса)
int handle; BX (входной параметр - указатель)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в регистр AX заносится код режима приема пакетов.
10. Занесение списка мультикастинг-адресов в интерфейс set_multicast_list(addrlst,len)
AH == 22 (код запроса)
char far *addrlst; ES:DI (адрес буфера, где лежат адреса)
int len; CX (длина списка адресов)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
6 NO_MULTICAST;
9 NO_SPACE;
14 BAD_ADDRESS.
Список адресов представляет собой счетную последовательность, начинающуюся с байта числа адресов в списке. На список адресов указывает комбинация регистров ES:DI. Сообщение NO_SPACE присылается, если указатель адреса отсутствует, или число адресов превосходит аппаратные возможности интерфейса. Прежде чем заносить список, полезно сначала ознакомиться с имеющимся уже списком, выполнив запрос get_multicast_list. При получении сообщения NO_SPACE рекомендуется попытаться установить режим приема 3 с помощью запроса set_rcv_mode.
11. Получение рабочего списка мультикастинг-адресов
get_multicast_list
AH == 23 (код запроса)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
6 NO_MULTICAST;
9 NO_SPACE.
При успешном выпонении запроса флаг carry=0, в регистр CX заносится длина списка адресов, а регистры ES:DI указывают на начало счетной оследовательности, где запрошенный список лежит. Прикладная программа не должна модифицировать этот список.
12. Получение статистических данных об ошибках и трафике через данный интерфейс
get_statistics(handle)
AH == 24 (код запроса)
int handle; BX (указатель)
char far *statistics; DS:SI (адрес буфера, куда записываются статистические данные)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки 1 BAD_HANDLE. При успешном выполнении запроса флаг carry=0, а в массиве, начиная с адреса DS:SI, лежит запрошенная информация.
struct statistics {
| unsigned long packets_in; | ( Число принятых пакетов для всех указателей) |
| unsigned long packets_out; | ( Число посланных пакетов) |
| unsigned long bytes_in; | ( Число принятых байтов, включая MAC заголовки) |
| unsigned long bytes_out; | ( Число посланных байтов) |
| unsigned long errors_in; | ( Полное число ошибок при приеме) |
| unsigned long errors_out; | ( Число ошибок при посылке пакетов) |
| unsigned long packets_lost; | ( Число потерянных пакетов из-за отсутствия свободного буфера или других ресурсов) |
/p> };
Статистические данные имеют вид целых 32-разрядных чисел в формате IBM/PC.
13. Смена физического адреса интерфейса
set_address(addr, len) AH == 25
char far *addr; ES:DI (адрес буфера, где лежит новое значение адреса)
int len; CX (длина адреса в байтах)
В случае ошибки флаг carry=1, а в регистр DH заносится код ошибки. Возможные ошибки:
13 CANT_SET;
14 BAD_ADDRESS.
При благоприятном выполнении запроса флаг carry=0, а значение регистра CX сохраняется.
Запрос используется в случае, когда необходим специфический физический адрес интерфейса (например, в случае DECNET). При наличии более одного указателя (handle) драйвер откажется исполнить данный запрос и пришлет сообщение CANT_SET.
Этим не исчерпывается перечень возможных запросов, существует некоторое количество операций, относящихся к экстра-набору функций (код функциональности 5 или 6, смотри описание запроса driver_info).
Сети ase-VG
4.1.11 Сети 100Base-VG
Семенов Ю.А. (ГНЦ ИТЭФ)
Сети 100BASE-VG (Voice Grade) используют звездообразную схему сетевых объектов с помощью соединения типа точка-точка. Эта разновидность сети может работать через кабельную инфраструктуру стандартной сети 10BASE-T. Станции подключаются к сети через концентратор (Hub). Когда станция желает что-либо передать, она посылает сигнал определенной частоты. Начало обмена стартует только после получения разрешения (сигнал специальной частоты, посылаемый концентратором. Широковещательные и мультикатинг-запросы обслуживаются в соответствии со схемой “запомнить и передать”. В одно и то же время допускается прием или передача только одного пакета. Для предоставления доступа используется карусельный принцип, что делает эту сеть весьма удобной для небольших рабочих групп и для решения задач управления в реальном масштабе времени. Имеется возможность и приоритетного обслуживания. В сети используется схема кодирования 5B/6B.
Сети DQDB (двойная шина с распределенной очередью)
4.1.9 Сети DQDB (двойная шина с распределенной очередью)
Семенов Ю.А. (ГНЦ ИТЭФ)
Сети с двойной шиной и распределенной очередью (DQDB - distributed queue dual bus) используют алгоритм доступа, называемый распределенное переключение пакетов (QPSX – queued-packet distributed-switch). Здесь используется две несвязанные однонаправленные шины, сформированные из цепочки соединений точка-точка. Описание работы сети содержится в документе IEEE 802.6. Пропускная способность сети составляет 150 Мбит/с (планируется 600 Мбит/с). Максимально возможная длина сети составляет 160 км. Максимальное число узлов равно 512. В качестве транспортной среды можно использовать одно- и мультимодовое оптическое волокно (длина волны 1300 нм). Схема кодирования 8В/9В при представлении сигнала NRZI. средняя частота ошибок (BER) составляет 10-9. По сетям DQDB пересылаются также как и по ATM-каналам ячейки фиксированного размера (L=53 байта). Формат поля данных совместим с некоторыми типами AAL. Формат пакета показан на рис 4.1.9.1
Рис. 4.1.9.1. Формат ячейки DQDB (цифры в верхней части рисунка характеризуют длины полей)
Поле ST (segment type) характеризует тип сегмента. Поле MID (message identifier) представляет собой идентификатор сообщения. LEN –характеризует длину поля данных, а CRC – это контрольная сумма ячейки. Когда станция намерена передать ячейку, она должна знать, справа или слева от нее находится место назначения. Если место назначения справа, отправитель использует шину А, в противном случае передача производится по шине В. Для ввода данных на шину применяется схема проволочного ИЛИ. По этой причине обесточенная станция не вызовет отказа всего сегмента сети. Станция образуют очередь для передачи в порядке поступления заявок (fifo). Структура заголовка ячейки показана на рис. 4.1.9.2 она весьма схожа с той, что имеет ячейка atm.
Рис. 4.1.9.2. Формат заголовка DQDB–пакета
Поле ACF (access control field) служит для управления доступом. Поле VCI (virtual cannel identifier) - виртуальный идентификатор канала. Далее следуют поля:
HEC
Рис. 4.1.9.3. Топология сети DQDB
Каждый из узлов подключен к обеим шинам. По каждой из шин всегда циркулирует фиксированное число контейнеров. Содержимое контейнеров может передаваться с одной шины на другую. В сети DQDB используются следующие типы сегментов:
одиночный сегмент (не нужно никакой сегментации);
первый сегмент (первая ячейка сегментированного МАС-кадра);
промежуточный сегмент фрагментируемого mac-кадра;
последний сегмент (последняя ячейка сегментированного МАС-кадра)
Поле MID остается идентичным для всех DQDB ячеек сегментированного МАС-кадра. Поле ACF содержит биты busy и request, которые используются в рамках механизма qpsx. Бит busy=1 указывает на то, что ячейка занята. Бит request=1 устанавливается узлом, который ждет возможности начать передачу. В каждом узле имеется счетчик запросов RC(request counter), который фиксирует число узлов, ожидающих передачи и стоящих в очереди впереди данного узла. Содержимое счетчика увеличивается всякий раз, когда по шине А проходит контейнер с битом busy=1. Счетчик декрементируется при появлении на шине Б контейнера со свободным битом request. Когда станция сама намеривается передать кадр, содержимое RC переносится в реверсивный счетчик DC, а в регистр RC заносится нуль. Код в DC уменьшается на единицу при получении контейнера с битом busy=1. DC определяет положение запроса в очереди (нуль соответствует началу очереди). Если получен контейнер с request=0 и DC=0, узел может передать ячейку по данной шине. Каждый узел может осуществлять передачу и прием по любой из шин А и Б. В сети DQDB предусмотрено 4 уровня приоритетов и каждый узел поддерживает до 5 очередей с RC и DC счетчиками для каждой из очередей. Для индикации приоритета в поле ACF предусмотрено 4 двоичных разряда (R1, R2, R3 и R4). Высшему приоритету соответствует R4. Схема сегментирования MAC-кадра при передаче с помощью DQDB ячеек показана на рис. 4.1.9.4.
Рис. 4.1.9.4. Сегментация МАС-кадра
Сети DQDB могут иметь размер до 160 км при скорости передачи данных 44,736 Мбит/с (Т3).
Сети IEEE
4.1.8 Сети IEEE 802.11
Семенов Ю.А. (ГНЦ ИТЭФ)
Технология беспроводных сетей развивается довольно быстро. Эти сети удобны для подвижных средств в первую очередь. Наиболее перспективным представляется проект IEEE 802.11, который должен играть для радиосетей такую же интегрирующую роль как 802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе 802.11 используется тот же алгоритм доступа и подавления cтолкновений, что и в 802.3, но здесь вместо соединительного кабеля используются радиоволны (Рис. 4.1.8.1.)
Рис. 4.1.8.1. Схема беспроводной локальной сети
Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц при использовании 4FSK/2FSK FHSS модуляции, мощность передатчика 10мВт-1Вт. Максимальная пропускная способность сети составляет 2 Мбит/с.
В 1992 году страны члены ЕС выделили диапазон частот 1,89-1,9 ГГц для целей построения сетей, базирующихся на применение радиосигналов (стандарт DECT - Digital European Cordless Telecommunications). Этот стандарт был разработан для целей передачи данных и голоса в системах сотовой связи. В США для этих же целей используются широкополосные системы с шумоподобным сигналом (SST - ШПС). Для подобных же целей выделены также частотные диапазоны 18 и 60ГГц (диапазон 2,4 ГГц сильно перегружен и “засорен” шумами). Существуют уже системы базирующиеся на Ethernet и Token Ring.
При относительно малых расстояниях проблем обычно не возникает и работу беспроводной сети действительно можно аппроксимировать алгоритмом CSMA. Но в случае, когда расстояние между передатчиком и приемником сравнимо с радиусом надежной связи, отличие от традиционных сетей становится значительным. Ведь для радиосетей важна интерференция на входе приемника, а не на выходе передатчика (как в CSMA). Рассмотрим вариант сети, изображенный на рис. 4.1.8.2. Если передачу осуществляет узел А, узел С находится вне его радиуса действия и может решить, что можно начать передачу. Излучение передатчика С может вызвать помехи на входе узла В (проблема скрытой станции).
Рис. 4.1.8.2. Схема взаимодействия узлов в беспроводной сети (MACA)
В случае, когда передачу ведет узел В, узел С может решить, что начало передачи сообщения узлу D не возможно, так как в зоне С детектируется излучение станции В (проблема засвеченной станции). Таким образом, в радиосетях, прежде чем начать передачу данных надо знать, имеется ли радио активность в зоне приемника-адресата. В коротковолновых сетях возможна одновременная передача для нескольких адресатов, если они находятся в разных зонах приема.
Ранние протоколы беспроводных локальных сетей базировались на схеме MACA (Multiple Access with Collision Avoidance), разработанной Ф. Карном в 1990 году. Эта схема является основой стандарта IEEE 802.11. В этой схеме отправитель запрашивает получателя послать короткий кадр, будучи принят соседями, предотвратит их передачу на время последующей передачи сообщения адресату. На рис. 4.1.8.2 узел В посылает кадр RTS (Request To Send) узлу C. Этот кадр имеет всего 30 октетов и содержит поле длины последующего сообщения. Узел C откликается посылкой кадра CTS (Clear To Send), куда копируется код длины последующего обмена из кадра RTS. После этого узел В начинает передачу. Окружающие станции, например D или E, получив CTS, воздерживаются от начала передачи на время, достаточное для передачи сообщения оговоренной длины. Станция A находится в зоне действия станции B, но не станции C и по этой причине не получит кадр CTS. По этой причине станция A может начинать передачу, если хочет и не имеет других причин, препятствующих этому. Несмотря на все предосторожности коллизия может иметь место. Например, станции A и C могут одновременно послать кадры RTS станции B. Эти кадры будут неизбежно потеряны, после псевдослучайной выдержки эти станции могут совершить повторную попытку (как в ETHERNET).
В 1994 году схема MACA была усовершенствована и получила название MACAW. Было отмечено, что без подтверждения на канальном уровне потерянные кадры не будут переданы повторно, пока транспортный уровень много позднее не обнаружит их отсутствия. В усовершенствованной схеме требуется подтверждение получения любого информационного кадра, добавлен также механизм оповещения о перегрузке.
К сожалению беспроводные, особенно мобильные каналы крайне ненадежны. Потери пакетов в таких каналах весьма вероятны. Понижение скорости передачи, как правило, не приводит к понижению вероятности потери. Кроме того, проходы от отправителя к получателю здесь неоднородны и могут включать в себя сегменты с различными методами транспортировки данных (проводные и беспроводные). В таких структурах бывает полезно разбить канал на две последовательные связи (indirect TCP). Преимуществом такой схемы является то, что оба виртуальных канала являются однородными. Таймауты в одном из соединений заставят отправителя замедлить темп передачи, в то время как таймауты во втором - могут ускорить обмен. Да и все остальные параметры связей могут оптимизироваться независимо. Основной недостаток этого приема заключается в нарушении базового принципа организации TCP-соединений на основе сокетов, здесь получение подтверждения отправителем не означает благополучной доставки. В 1995 году была предложена схема, не нарушающая TCP-семантику. В этой схеме вводится специальный агент-наблюдатель, который отслеживает состояние кэшей отправителя и получателя и посылает подтверждения. Этот агент при отсутствии своевременного подтверждения запускает процедуру повторной посылки сегмента, не информируя об этом первичного отправителя. Механизмы подавления перегрузки запускаются в этом варианте только при перегрузке проводной секции канала. При потерях реализуется выборочная пересылка сегментов.
При работе с UDP также возникают некоторые трудности. Хотя известно, что UDP не гарантирует доставки, большинство программ, предполагает, что вероятность потери невелика. Программы используют такие способы преодоления потерь, которые при высокой вероятности потери просто не срабатывают. Многие приложения предполагают наличие достаточного запаса пропускной способности, чего в случае мобильной связи обычно нет.
Сети передачи данных Методы доступа
4 Сети передачи данных. Методы доступа
Семенов Ю.А. (ГНЦ ИТЭФ)
Топология
Среди топологических схем наиболее популярными являются (см. рис. 4.1):
Шина
Звезда
Кольцо
Многокаскадные и многосвязные сети (См. раздел 4.1.10; 41\ban_4110.doc)
Рис. 4.1. Примеры сетевых топологий
К первым трем типам топологии относятся 99% всех локальных сетей. Наиболее популярный тип сети – Ethernet, может строиться по схемам 1 и 2. Вариант 1 наиболее дешев, так как требует по одному интерфейсу на машину и не нуждается в каком-либо дополнительном оборудовании. Сети Token Ring и FDDI используют кольцевую топологию (3 на рис. 4.1), где каждый узел должен иметь два сетевых интерфейса. Эта топология удобна для оптоволоконных каналов, где сигнал может передаваться только в одном направлении (но при наличии двух колец, как в FDDI, возможна и двунаправленная передача). Нетрудно видеть, что кольцевая топология строится из последовательности соединений точка-точка.
Используется и немалое количество других топологий, которые являются комбинациями уже названных. Примеры таких топологий представлены на рис. 4.2.
Вариант А на рис. 4.2 представляет собой схему с полным набором связей (все узлы соединены со всеми), такая схема используется только в случае, когда необходимо обеспечить высокую надежность соединений. Эта версия требует для каждого из узлов наличия n-1 интерфейсов при полном числе узлов n. Вариант Б является примером нерегулярной топологии, а вариант В – иерархический случай связи (древовидная топология).
Если топологии на рис. 4.1 чаще применимы для локальных сетей, то топологии на рис. 4.2 более типичны для региональных и глобальных сетей. Выбор топологии локальной или региональной сети существенно сказывается на ее стоимости и рабочих характеристиках. При этом важной характеристикой при однородной сети является среднее число шагов между узлами d. 
Рис. 4.2. Различные сетевые топологические схемы
Современные вычислительные системы используют и другие топологии: решетки (А), кубы (В), гипердеревья (Б), гиперкубы и т.д. (см. рис. 4.3). Но так как некоторые вычислительные системы (кластеры) базируются на сетевых технологиях, я привожу и такие примеры. В некоторых системах топология может настраиваться на решаемую задачу.
Рис. 4.3. Некоторые топологии вычислительных систем
Метод доступа к сети
Метод доступа определяет метод, который используется при мультиплексировании/демультиплексировании данных в процессе передачи их по сети. Большая часть современных сетей базируется на алгоритме доступа CSMA/CD (carrier sensitive multiple access with collision detection), где все узлы имеют равные возможности доступа к сетевой среде, а при одновременной попытке фиксируется столкновение и сеанс передачи повторяется позднее. Здесь нет возможности приоритетного доступа и по этой причине такие сети плохо приспособлены для задач управления в реальном масштабе времени. Некоторое видоизменение алгоритма CSMA/CD (как это сделано в сетях CAN или в IBM DSDB) позволяют преодолеть эти ограничения. Доступ по схеме CSMA/CD (из-за столкновений) предполагает ограничение на минимальную длину пакета. По существу, метод доступа CSMA/CD предполагает широковещательную передачу пакетов (не путать с широковещательной адресацией). Все рабочие станции логического сетевого сегмента воспринимают эти пакеты хотя бы частично, чтобы прочесть адресную часть. При широковещательной адресации пакеты не только считываются целиком в буфер, но и производится прерывание процессора для обработки факта прихода такого пакета. Логика поведения субъектов в сети с доступом CSMA/CD может варьироваться. Здесь существенную роль играет то, синхронизовано ли время доступа у этих субъектов. В случае Ethernet такой синхронизации нет. В общем случае при наличии синхронизации возможны следующие алгоритмы.
А.
Если канал свободен, терминал передает пакет с вероятностью 1.
Если канал занят, терминал ждет его освобождения, после чего производится передача.
Б.
Если канал свободен, терминал передает пакет.
Если канал занят, терминал определяет время следующей попытки передачи. Время этой задержки может задаваться некоторым статистическим распределением.
В.
Если канал свободен, терминал с вероятностью р передает пакет, а с вероятностью 1-р он откладывает передачу на t секунд (например, на следующий временной домен).
При повторении попытки при свободном канале алгоритм не изменяется.
Если канал занят, терминал ждет пока канал не освободится, после чего действует снова согласно алгоритму пункта 1.
Алгоритм А на первый взгляд представляется привлекательным, но в нем заложена возможность столкновений с вероятностью 100%. Алгоритмы Б и В более устойчивы в отношении этой проблемы.
Следующим по популярности после csma/cd является маркерный доступ (Token Ring, Arcnet и FDDI), который более гибок и обеспечивает приоритетную иерархию обслуживания. Массовому его внедрению препятствует сложность и дороговизна. Хотя региональные сети имеют самую разнообразную топологию, практически всегда они строятся на связях точка-точка.
В таблице 4.1 представлены сводные данные по основным видам локальных сетей, используемых в настоящее время (список не является полным).
Таблица 4.1. Параметры различных локальных сетей
|
Название сети |
Топология |
Быстродействие Мбит/с |
Доступ |
Тип кабеля |
NEXT при макс. частоте [дб] |
Размер сети (сегмента) |
Макс. число узлов |
| 10base5 | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 500м | 1024 | |
| 10base2 | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 185 м | 90 | |
| 10base-t | шина | 10 | CSMA/CD | UTP (III; 100 Ом) | 26 | 100 м | - |
| 10broad36 | шина | 10 | CSMA/CD | RG-59 (75 Ом) | 3600 м | 1024 | |
| 100base-tx | звезда | 100 | CSMA/CD | UTP (v; 100 Ом) | 29 | 200 м | - |
| 100base-fx | звезда | 100 | CSMA/CD | оптоволокно | 300 м | - | |
| 100base-t4 | звезда | 100 | CSMA/CD | UTP (III; 100 Ом) | 21 | 200 м | - |
| 1base5 (starlan) | шина/ звезда | 1 | CSMA/CD | UTP (II) | 22 | 400 м | 1210 |
| IEEE 802.4 | шина | 1/5/10/20 | маркер | RG-59 (75 Ом) | |||
| Arcnet | звезда | 2,5/20 | маркер | RG-62/utp (93 Ом) | 600/125м | 255 | |
| IEEE 802.5 | звезда | 4/16 | маркер | STP/UTP (150/120 Ом) | 22/32 | 366 м | 260 |
| Appletalk |
шина/ звезда |
0,23 | CSMA/CD | STP/UTP (100 Ом) | 22/32 | 300/3000 м | 32 на сегмент |
| Ethertalk |
шина/ звезда |
10 | CSMA/CD | STP/UTP, коаксиальный кабель | 500/3000 м | 254/1023 | |
| ISN | звезда | 8,64 | Шина доступа | stp, оптоволокно | Не ограничено | 336/1920 | |
| pc lan | дерево, звезда | 2 | CSMA/CD | RG-59 (75 Ом), UTP/STP |
32/22 |
2000 | 72 |
| Hyperchannel | шина | 50 | CSMA/CD | RG-59, оптоволокно | 3500 м | 256 | |
| e-net | шина | 10 | CSMA/CD | RG-58 (50 Ом) | 700 м | 100 | |
| G-net | шина | 1 | CSMA/CD | RG-58, RG-59 | 2000 м | 100 | |
| FDDI | Двойное кольцо | 100 | маркер | оптоволокно | 100км | 1000 | |
| PX-net | шина/ звезда | 1 | маркер | RG-62 (93 Ом) | 7000 м | 100 | |
| S-net | шина/ звезда | 1 | Индивидуальный | STP (100 Ом) | 21 | 700 м | 24 |
| wangnet | двойное дерево | 10 | CSMA/CD | RG-59 (75 Ом) | 2800 м | 65000 |
/p> Приведенная таблица не может претендовать на полноту. Так сюда не вошла сеть IBM DSDB, разработанная в начале 80-х годов. Полоса пропускания сети составляет 64 Мбит/с. Эта сеть рассчитана на обслуживания процессов реального времени. Сеть имеет топологию шины с приоритетным доступом (длина шины до 500м). Коммуникационная шина логически делится на три магистрали: сигнальная – для реализации приоритетного доступа; лексемная шина для резервирования в буфере места назначения; и, наконец, коммуникационная шина для передачи данных. Каждая из указанных магистралей использует идеологию независимых временных доменов, границы которых синхронизованы для всех трех магистралей. Схема доступа сходна с описанной для сетей CAN (см. раздел 4.1.4).
Узел, пытающийся получить доступ к одной из магистралей, выдает свой физический адрес и приоритет сообщения бит за битом.
При этом узел мониторирует состояние магистрали, проверяя, соответствует ли уровень сигнала тому, что он передает.
Если имеет место совпадение, передается следующий бит и осуществляется процедура пункта 2. При несовпадении узел прерывает передачу, возвращается к пункту 2 и ждет следующего цикла.
Данная схема доступа исключает столкновения, характерные для CSMA. Именно это преимущество делает сеть применимой для задач реального времени.
Существует целое семейство методов доступа, исключающих столкновение: это мультиплексирование по времени (TDM) и по частоте (FDM). Здесь каждому клиенту выделяется определенный временной домен или частотный диапазон. Когда наступает его временной интервал и клиент имеет кадр (или бит), предназначенный для отправки, он делает это. При этом каждый клиент ждет в среднем n/2 временных интервалов (предполагается, что работает n клиентов). При FDM передача не требует ожидания. Но в обоих случаях временные интервалы или частотные диапазоны используются клиентом по мере необходимости и могут заметное время быть не заняты (простаивать). Такие протоколы доступа часто используются в мобильной связи.
Интересной разновидностью Ethernet является широкополосная сеть типа Net/one. Она может базироваться на коаксиальном кабеле (суммарная длина до 1500м) или на оптическом волокне (полная длина до 2500м). Эта сеть по многим характеристикам аналогична обычному ethernet (CSMA/CD) за исключением того, что коммуникационное оборудование передает данные на одной частоте, а принимает - на другой. Для каждого канала выделяется полоса 5 Мбит/с (полоса пропускания 6МГц соответствует телевизионному стандарту). Предусматривается 5 передающих (59,75-89,75 МГц) и 5 принимающих (252-282 МГц) каналов для каждого из сетевых сегментов. Частота ошибок (BER) для сети данного типа меньше 10-8.
Другой Ethernet-совместимой сетью является Fibercom Whispernet. Сеть имеет кольцевую структуру (до 8км), полосу пропускания 10Мбит/c, число узлов до 100 на сегменте при полном числе узлов в сети – 1024. Число кольцевых сегментов может достигать 101. Максимальное межузловое расстояние – 2км.
Примером нетрадиционного типа сети может служить Localnet 20 (Sytek). Сеть базируется на одном коаксиальном кабеле и имеет полную полосу пропускания 400 МГц. Сеть делится на 120 каналов, каждый из которых работает со скоростью 128 Кбит/с. Каналы используют две 36МГц-полосы, одна для передачи, другая для приема. Каждый из коммуникационных каналов занимает 300КГц из 36МГц. Сеть использует алгоритм доступа CSMA/CD, что позволяет подключать к одному каналу большое число сетевых устройств. Предусматривается совместимость с интерфейсом RS-232. Частота ошибок в сети не более 10-8.
Фирма Дженерал Электрик разработала сеть gm (map-шина), совместимую со стандартом IEEE 802.4. Целью разработки было обеспечение совместимости с производственным оборудованием различных компаний. Сеть рассчитана на работу со скоростями 1, 5 и 50 Мбит/с.
Традиционные сети и телекоммуникационные каналы образуют основу сети – ее физический уровень. Реальная топология сети может динамически изменяться, хотя это и происходит обычно незаметно для участников. При реализации сети используются десятки протоколов. В любых коммуникационных протоколах важное значение имеют операции, ориентированные на установление связи (connection-oriented) и операции, не требующие связи (connectionless - "бессвязные", ISO 8473). Интернет использует оба типа операций. При первом типе пользователь и сеть сначала устанавливают логическую связь и только затем начинают обмен данными. Причем между отдельными пересылаемыми блоками данных (пакетами) поддерживается некоторое взаимодействие. "Бессвязные" операции не предполагают установления какой-либо связи между пользователем и сетью (например, протокол UDP) до начала обмена. Отдельные блоки передаваемых данных в этом случае абсолютно независимы и не требуют подтверждения получения. Пакеты могут быть потеряны, задублированы или доставлены не в порядке их отправки, причем ни отправитель, ни получатель не будут об этом оповещены. Именно к этому типу относится базовый протокол Интернет - IP.
Для каждой сети характерен свой интервал размеров пакетов. Среди факторов, влияющих на выбор размеров можно выделить
Аппаратные ограничения, например размер домена при мультиплексировании по времени.
Операционная система, например размер буфера 512 байт.
Протокол (например, число бит в поле длины пакета).
Обеспечение совместимости с определенными стандартами.
Желание уменьшить число ошибок при передаче ниже заданного уровня.
Стремление уменьшить время занятости канала при передаче пакета.
Ниже приведены максимальные размеры пакетов (mtu) для ряда сетей
| Сеть |
MTU Байт |
Быстродействие Мбит/с |
| IEEE 802.3 | 1500 | 10 |
| IEEE 802.4 | 8191 | 10 |
| IEEE 802.5 | 5000 | 4 |
"бессвязная" доставка пакетов;
надежная транспортировка информации;
реализация прикладных задач.
Немногие из читателей участвуют в создании региональных и тем более глобальных сетей, за то структура и принципы построения локальных сетей им, безусловно, близки. На рис. 4.4 и 4.5 приведены два варианта “ресурсных” локальных сетей (сети для коллективного использования ресурсов – памяти, процессоров, принтеров, магнитофонов и т.д.). Такие сети строятся так, чтобы пропускная способность участков, где информационные потоки суммируются, имели адекватную полосу пропускания. Эффективность сети на рис. 4.4 сильно зависит от структуры и возможностей контроллеров внешних устройств, от объема их буферной памяти.
Рис. 4.4. Вариант схемы ресурсной локальной сети
Сеть, показанная на рис. 4.5, несравненно более эффективна (практически исключены столкновения и легче гарантировать определенное время доступа к ресурсу). Здесь также немало зависит от свойств контроллеров внешних ресурсов (помечены красным цветом). Но такие сети обычно более дорого реализовать.
Рис. 4.5.
Для сопоставления быстродействия различных видов сетей Сталлингс (Stallings, W.: Data and Computer Communications, New York: Mac-Millan Publishing Company, 1985) в 1985 году разработал критерий. Критерий предполагает вычисление битовой длины BL (максимальное число бит в сегменте), которая равна произведению максимальной длины сегмента (L) на полосу пропускания (W), деленное на скорость распространения сигнала в сегменте (S):
BL = l*W/S
Для Ethernet BL = [500(м)*10 106(бит/c)]/2 108 (м/c) = 25 бит.
Коэффициент использования сети равен b = 1/(1+a), где
Принципы построения сетевых программных интерфейсов
Существует большое разнообразие сетевых интерфейсов. Их структура зависит от характера физического уровня сетевой среды, от метода доступа, от используемого набора интегральных схем и т.д.. Здесь пойдет речь о принципах построения программного интерфейса (см. также раздел 7; ..\7\soft_7.htm).
Существует три возможности построения интерфейса: с базированием на памяти, с использованием прямого доступа и с применением запросов обслуживания.
Первый вариант предполагает наличие трех компонентов: буфер сообщений, область данных для управления передачей и зона памяти для управления приемом данных. Первый из компонентов служит для формирования исходящих сообщений программного интерфейса. Должны быть приняты меры, чтобы исключить модификацию содержимого этого буфера до того, как данные будут считаны ЭВМ или интерфейсом. Проблема решается путем формирования соответствующих указателей. Управление буфером осуществляется ЭВМ или совместно ЭВМ и интерфейсом с использованием механизма семафоров.
Остальные методы связаны с использованием традиционных методов управления памятью с помощью средств операционной системы. Критической проблемой является обеспечение достаточного места в буфере для приходящих сообщений. Ведь в отсутствии памяти приходящее или записанное ранее сообщение может быть потеряно. Недостаток места для исходящих сообщений не является критическим, так как приводит обычно к задержке передачи, а не к потере сообщения.
Второй компонент интерфейса, базирующегося на использовании памяти, часто реализуется в виде так называемых буферов управления передачей (TCB). Эти буферы содержат такую информацию как положения сообщения в памяти, длина сообщения, адрес места назначения, идентификатор процесса-отправителя, приоритет сообщения, предельное значение числа попыток передачи, а также флаг, указывающий на необходимость присылки подтверждения от получателя. TCB (transmission control buffer) создается процессом-отправителем и передается интерфейсу, после завершения записи в буфер сообщений. Параметры TCB используются интерфейсом при организации процесса передачи сообщения.
Третий компонент интерфейса, базирующегося на использовании памяти, называется буфером управления приемом (RCB – Reception Control Buffer). RCB содержит в себе информацию, сходную с той, что записывается в TCB, например, идентификатор отправителя, длина сообщения, индикатор ошибки, время приема и идентификатор процесса места назначения. RCB заполняется интерфейсом при получении сообщения и передается процессору ЭВМ. Основополагающим принципом построение всех трех компонент является совместное использование памяти и гибкая система указателей. Версия программы, рассмотренная в разделе 7 ближе именно к этой схеме взаимодействия.
Во втором варианте широко используемой схемы доступа к сети (“прямой доступ”) взаимодействие ЭВМ и интерфейса строится по схеме клиент-сервер. Конкретная реализация программы в этом случае в большей степени зависит от структуры регистров физического интерфейса.
В третьем варианте сетевого программного интерфейса используются служебные запросы. Этот тип сетевого доступа удобен для коммуникационных протоколов высокого уровня, таких как команды ввода/вывода CSP-стиля (Communicating Sequential Processes) или процедуры обмена языка Ада. В этом методе накладываются определенные ограничения на реализацию нижележащих коммуникационных уровней.
Программирование для сетей существенным образом является программированием для процессов реального времени. Здесь часто можно столкнуться с тем, что одна и та же программа ведет себя по-разному в разных ситуациях. Особое внимание нужно уделять написанию многопроцессных сетевых программ, где также как в случае (см. раздел 7.1; ..\7\sock_71.htm) работы с соединителями могут возникать ситуации блокировок. Пример такой ситуации показан на рис. 4.6.
Рис. 4.6.
Когда число процессов больше, заметить запрограммированную ситуацию блокировки заметно сложнее. По этой причине необходимо предусмотреть меры препятствующие блокировке, если ожидаемое сообщение не пришло.
Необычайно важной проблемой при построении сетей является их устойчивость при возникновении перегрузок. В Интернет для этого используется специальная опция протокола ICMP, а во Frame Relay имеются меры для преодоления перегрузок непосредственно на нижних протокольных уровнях.
Методы работы в условиях перегрузки
Оптимальность управления сетью в условиях перегрузок определяет эффективность использования сети. Пока субсеть загружена незначительно, число принимаемых и обрабатываемых пакетов равно числу пришедших. Однако, когда в субсеть поступает слишком много пакетов может возникнуть перегрузка и рабочие характеристики деградируют. При очень больших загрузках пропускная способность канала или сети может стать нулевой (см. [39]) Такая ситуация называется коллапсом сети.
Отчасти это может быть связано с недостатком памяти для входных буферов, по этой причине некоторое увеличение памяти может помочь. Но следует помнить, что всякое лекарство хорошо в меру. Еще в 1987 году Нагле (Nagle) обнаружил, что если маршрутизатор имеет даже беспредельную память, эффект перегрузки может оказаться еще более тяжелым. Это сопряжено со временем, которые пакеты ожидают обработки. Если время ожидания в очереди превышает длительность таймаута, появятся дубликаты пакетов, что, безусловно, понижает эффективность системы. Причиной перегрузки может быть медленный процессор или недостаточная пропускная способность какого-то участка сети. Простая замена процессора или интерфейса на более быстродействующий не всегда решает проблему - чаще переносит узкое место в другую часть системы. Перегрузка, как правило, включает механизмы, усиливающие ее негативное воздействие. Так переполнение буфера приводит к потере пакетов, которые позднее должны будут переданы повторно (возможно даже несколько раз). Процессор передающей стороны получает дополнительную паразитную загрузку. Все это указывает на то, что контроль перегрузки является крайне важным процессом. Следует делать различие между контролем потока и контролем перегрузки. Под контролем потока подразумевается балансировка потока отправителя и возможности приема и обработки получателя. Этот вид контроля предполагает наличие обратной связи между получателем и отправителем. В этом процессе участвуют, как правило, только два партнера. Перегрузка же более общее явление, относящееся к сети в целом или к какой-то ее части. Например, 10 ЭВМ хотят передать одновременно какие-то файлы другим 10 ЭВМ. Конфликта потоков здесь нет, каждая из ЭВМ способна переработать поступающие данные, но сеть не может пропустить поток, генерируемый 10 сетевыми интерфейсами одновременно. Часто эти явления не так просто разделить. Отправитель может получить сообщение ICMP (quench) (в случае TCP/IP) при перегрузке получателя или при перегрузке какого-то сегмента сети.
Начинать надо с решения проблемы выявления перегрузок. Перегрузкой следует считать ситуацию, когда нагрузка в течение некоторого оговоренного времени превышает заданную величину. Параметрами, которые позволяют судить о наличии перегрузки могут служить:
процент пакетов, отбрасываемых из-за отсутствия свободного буферного пространства.
средняя длина очереди
процент пакетов, пересылаемых повторно
среднее время задержки пакета и некоторые другие величины
Когда перегрузка выявлена, нужно передать необходимую информацию из точки, где она обнаружена, туда, где можно что-то сделать для исправления ситуации.
Можно послать уведомление о перегрузке отправителю, загружая дополнительно и без того перегруженный участок сети. Альтернативой этому может быть применение специального поля в пакете, куда маршрутизатор может записать соответствующий код при перегрузке, и послать его соседям. Можно также ввести специальный процессор или маршрутизатор, который рассылает периодически запросы о состоянии элементов сети. При получении оповещения о перегрузки информационный поток может быть послан в обход.
При использовании обратной связи путем посылки сообщения-запроса понижения скорости передачи следует тщательно настраивать временные характеристики. В противном случае система либо попадает в незатухающий осциллятивный режим, либо корректирующее понижение потока будет осуществляться слишком поздно. Для корректного выбора режима обратной связи необходимо некоторое усреднение.
Преодоление перегрузки может быть осуществлено понижением нагрузки или добавлением ресурсов приемнику.
Положительный результат может быть достигнут изменением механизма подтверждения (например, уменьшением размера окна), вариацией значений таймаутов, вариацией политики повторной передачи пакетов. В некоторых случаях позитивный результат может быть получен изменением схемы буферизации. Иногда решить проблему может маршрутизатор, например, перераспределяющий трафик по нескольким направлениям.
Одной из причин перегрузки часто являются импульсные загрузки сегмента сети или сетевого устройства. По этой причине любые меры (напр., pipelining), которые могут выравнять поток пакетов, безусловно улучшат ситуацию (например, traffic shaping в сетях ATM). В TCP же с его окнами импульсные загрузки предопределены.
Алгоритм leaky bucket ("дырявое ведро")
Для систем без обратной связи решение проблемы выравнивания скорости передачи данных может быть решено с помощью алгоритма leaky bucket. Суть этого алгоритма заключается в том, что на пути потока устанавливается буфер выходной поток которого постоянен и согласован с возможностью приемника. Если буфер переполняется, пакеты теряются. Потеря пакетов вещь мало приятная, но это блокирует процессы, которые могут привести к коллапсу сегмента или всей сети. Там, где потеря пакетов нежелательна, можно применить более гибкий алгоритм.
Алгоритм Token Bucket ("маркерное ведро")
Алгоритм token bucket предполагает наличие в буферном устройстве (или программе) некоторого количества маркеров. При поступлении на вход буфера пакетов маркеры используются для их транспортировки на выход. Дальнейшая передача данных на выход зависит от генерации новых маркеров. Поступающие извне пакеты тем временем накапливаются в буфере. Таким образом, полной гарантии отсутствия потерь мы не имеем и здесь. Но алгоритм token bucket позволяет передавать на выход "плотные" группы пакетов ограниченной численности (по числу маркеров), снижая в некоторых случаях вероятность потери. Если буферное устройство "смонтировано" внутри ЭВМ-отправителя, потерь можно избежать вовсе, блокируя передачу при заполнении буфера. Как в одном так и в другом алгоритме мерой передаваемой информации может быть не пакет, а n-байт (где n некоторое оговоренное заранее число).
В системах, где управление трафиком осуществляется с использованием обратной связи, можно достичь большей эффективности. Одним из механизмов преодоления перегрузок является управление разрешением (admission control). Суть метода заключается в том, что при регистрации перегрузки не формируется более никаких виртуальных соединений до тех пор, пока ситуация не улучшится. Альтернативным вариантом может служить решение, где формирование нового соединения разрешается, но при этом осуществляется маршрутизация так, чтобы обойти узлы, в которых выявлена перегрузка (смотри рис. 4.7 ).
Рис. 4.7. Выбор маршрута нового виртуального канала при наличии перегрузки
На рис. 4.7 (верх) показан пример сети с двумя узлами, характеризующимися перегрузкой (помечены красным цветом). Предположим, что необходимо проложить виртуальный канал из узла А в узел Б. Из графа маршрутов удаляются перегруженные узлы, после чего осуществляется прокладка пути. В нижней части рисунка синим цветом показан новый виртуальный канал.
Еще более универсальным решение, пригодным для работы с установлением соединения и без, является посылка пакетов блокировки (choke packets). Маршрутизатор обычно контролирует загруженность всех своих внешних каналов l, которая может принимать значения от 0 до 1. Когда l достигает некоторого порогового значения, отправителю посылается пакет блокировки. При вычислении l следует использовать какую-либо методику усреднения, чтобы избежать слишком частых блокировок.
Когда отправитель получает пакет блокировки, он должен уменьшить трафик, посылаемый получателю на заданное число процентов. Так как на пути к месту назначения может быть много пакетов, это вызовет серию пакетов блокировки. Отправитель должен игнорировать пакеты блокировки в течение некоторого времени после получения первого такого пакета. По истечении этого периода отправитель прослушивает канал на протяжении аналогичного времени, ожидая получения новых пакетов блокировки. Если такой пакет приходит, канал все еще перегружен и отправитель снова должен понизить темп посылки пакетов. Если на протяжение периода прослушивания не приходит новых пакетов блокировки, отправитель может увеличить поток снова.
ЭВМ может понижать трафик, корректируя свои параметры, например, ширину окна или темп передачи на выходе устройства типа "дырявое ведро". Обычно первый блокирующий пакет уменьшает поток вдвое, следующий на 0,25 от первичного и т.д. Увеличение потока также производится аналогичными шагами. Существует большое число вариантов алгоритма управления потоком с использованием пакетов блокировки. Параметром, который контролируется и определяет условие отправки пакета блокировки, может служить длина очереди или заполненность буфера.
Ситуация перегрузки не всегда управляется однозначно. Например, при поступлении на вход пакетов от трех источников возможна ситуация, когда приемник посылает блокирующие пакеты всем отправителям, а откликнется сокращением потока только один. В результате этот узел, который "играет по правилам" (как это часто бывает и в жизни) оказывается в проигрыше. В 1987 году Нагле был предложен алгоритм fair queueing (честная очередь). В этом алгоритме маршрутизатор организует независимые очереди для пакетов, поступающих от разных источников. Когда выходной канал маршрутизатора оказывается свободным, он просматривает очереди циклически и отравляет очередной пакет. В результате при n очередях по завершении такого цикла просмотров-посылок оказываются посланы по одному пакету из каждой очереди. Такой алгоритм используется в некоторых ATM-переключателях. Следует заметить, что этот алгоритм дает некоторые преимущества тем узлам, которые посылают более длинные пакеты. Демерс (Demers) и др. в 1990 году предложил некоторое усовершенствоввание алгоритма. В данном варианте организуется циклический просмотр очередей не по-пакетно, а по-байтно. Система последовательно сканирует очереди и определяет положение концов пакетов. Первыми отправляются более короткие пакеты. Для иллюстрации предлагается рассмотреть рис. 4.8. (см. также [39])
Рис. 4.8. Маршрутизатор с 4-мя входными каналами, в каждом из которых ждет очереди передачи по одному пакету. В правой части рисунка представлен порядок посылки этих пакетов.
Пакеты на рисунке имеют от трех до девяти октетов. Порядок пересылки октетов показан в левой части рисунка. В отсутствии поступления новых пакетов, кадры, записанные в буфер будут переданы в порядке, представленном в правой части рисунка. Особенностью этого алгоритма является равенство приоритета всех входных каналов.
При передаче данных на большие расстояния с большими значениями RTT эффективность использования метода блокирующих пакетов снижается. Пока блокирующий пакет дойдет через ряд промежуточных узлов до отправителя, на вход получателя поступит большое число пакетов, которые не только усугубят ситуацию перегрузки, но и могут вызвать потерю какой-то их доли, что, в свою очередь, может потребовать повторной пересылки следовавших за ними кадров. Для повышения эффективности часто применяется схема, при которой блокирующие пакеты воздействуют на все маршрутизаторы по пути своего следования. В этом случае снижения потока можно ожидать уже чарез время, равное RTT до узла, ближайшего к получателю пакетов. Такая схема требует того, чтобы все промежуточные узлы имели достаточно емкие буферы, в противном случае возможны потери.
В протоколе TCP используется алгоритм управления трафиком, называемый "скользящее окно". Здесь размер окна, которое определяет число сегментов, посылаемых без получения подтверждения, варьируется в зависимости от наличия потерь пакетов. При большой вероятности потери система переходит в режим, когда очередной пакет не посылается до тех пор, пока не будет подтверждено получение предшествующего. При серьезных перегрузках, когда потери становятся значительными, нарушается механизм вычисления значений RTT и таймаутов, что может приводить к трудно предсказуемым последствиям. Следует обратить внимание, что в протоколе UDP какого-либо механизма управления трафиком не предусмотрено. По этой причине для некоторых мультимедийных задач, следует предусматривать другие, например, ICMP-способы подавления перегрузки. В приложениях типа NFS, где используется UDP, для подавления перегрузки используется упомянутый выше ICMP-механизм. К сожаления в ряде мультимедийных приложений потеря пакетов не контролируется (например IP-телефония). Там шлюз 100-10Мбит/с может восприниматься как канал с вероятностью потери пакета 90%.
Если другие способы испробованы, а перегрузка не исчезла, маршрутизатор начинает отбрасывать приходящие пакеты, которые уже не может обработать. Самое простое - это предоставить случаю выбор отбрасываемых пакетов. Но это не лучшая тактика. В случае пересылки мультимедийных данных предпочтение следует делать для последних полученных пакетов, а "старые" пакеты выбрасывать. При передаче файлов наоборот "старый" пакет имеет приоритет, ведь если его отбросить, придется повторно передавать не только его, но и все последующие пакеты. Некоторые методы передачи изображения требуют передачи время от времени всего кадра с последующей пересылкой только фрагментов, где произошли изменения. В таких условиях потеря пакета, составляющего базовый кадр, менее желательна. Сходные обстоятельства могут возникать и в других приложениях. Можно помечать пакеты, присваивая им определенные уровни приоритетов, что позволит осознанно принимать решение об отбрасывании того или иного пакета в условиях перегрузки. В перспективе проблема может быть решена на чисто коммерческой основе - компонента трафика, помеченная как высоко приоритетная, будет оплачиваться по более высокому тарифу. В некоторых сетях определенное количество пакетов объединяется в группы, образующие сообщение. Если одна ячейка такого сообщения выбрашена, все сообщение будет повторно переслано (смотри, например, адаптационные уровни сетей ATM).
Сети Петри
10.24 Сети Петри
Семенов Ю.А. (ГНЦ ИТЭФ)
Протоколы можно описывать не только с помощью модели машины конечных состояний. Альтернативой можно считать сети Петри (смотри, также книгу "Сети Петри", Котов В.Е., Москва, "Наука", ГРФМЛ, 1984 откуда взяты некоторые примеры и фрагменты данной статьи). Модель сети Петри является принципиально асинхронной и служит для отображения и анализа причинно-следственных связей в системе. Для привязки к определенным моментам времени тех или иных переходов в синхронных системах используются события. Переходы из состояния в состояния считаются "мгновенными". Если переход реально происходит через какие-то промежуточные состояния, а нам существенно учесть в модели эти обстоятельства, то вводятся соответствующие "подсобытия". Сеть Петри имеет четыре базовых элемента: позиции (places), переходы, дуги и метки (token).
Позиция (место) - это состояние, в котором находится система или определенная ее часть. Смотри рис. 10.24.1.
Рис. 10.24.1. Сеть Петри с двумя позициями и двумя переходами. Цифрами 1 и 2 обозначены переходы, а буквами А и Б - позиции.
Состояние системы формируется в результате реализации локальных операций, называемых условиями реализации событий. Условие имеет емкость:
Условие не выполнено - емкость равна нулю
Условие выполнено - емкость равна 1.
Условие выполнено с n-кратным запасом - емкость равна n.
Определенная комбинация условий может стимулировать определенное событие, которое вызовет в свою очередь изменение изменение условий. В сетях Петри события и условия отображаются абстрактными символами, называемыми переходами(вертикальными или горизонатальными полосками - "барьерами") и позициями (кружками). Условия-позиции и события-переходы связаны отношениями зависимости, которые отображаются с помощью ориентированных дуг. Позиции, из которых исходят дуги данного перехода, называются входными позициями. Позиции же, к которым ведут дуги данного перехода, называются выходными позициями. Выполнение условий отображается помещением соотвествтующего числа меток в соответствующую позицию. Если число меток велико (более 2-3), емкость условия может быть отображена числом.
В исходный момент система находится в состоянии А, что отмечено на рис. 4.9. меткой в виде синего кружочка. Переходы обозначаются горизонтальными или вертикальными линиями. Каждый переход имеет нуль или более входных дуг, исходящих из позиций, и нуль или более исходящих дуг, направленных к выходным позициям. Переход разрешен, если имеется как минимум одна входая метка в каждой из его исходных позиций. Любой разрешенный переход может произойти (fire), удалив все входные метки и установив метки в выходных позициях, что отражает изменение условий (и емкостей). Если числа входных и выходных дуг отличаются, число меток не сохраняется. Если разрешено более одного перехода, может произойти любой из них. Причем один из осуществившихся переходов, может блокировать реализацию всех остальных переходов из данного набора. Формализм сетей Петри не предусматривает каких-либо механизмов преодоления подобных конфликтов. Переход осуществляется, если выполнены все условия реализации данного события. Если два или более переходов могут осуществиться (выполнены все условия) и они не имеют общих входных позиций, то из реализация некоррелирована и может происходить параллельно или в любой последовательности. Выбор перехода, вообще говоря, не определен. В отличии от модели машины конечных состояний здесь отсутствуют комбинированные состояния типа отправитель-канал-получатель, и переходы из состояния в состояние для каждого процесса или объекта рассматриваются независимо. Если условия ни для одного из переходов не реализованы, сеть переходит в заблокированное состояние.
Аналитическое определение. Сеть Петри - набор N = (P, T, F, W, M0), где (P, T, F) - конечная сеть (множество Х = ЗuT конечно), а W: F> N\ {O} (знак \ здесь означает разность множеств) и M0: P>N - две функции, называемые кратностью дуг и начальной пометкой. Первая ставит в соответствие каждой дуге число N>0 (кратность дуги). Если N>0, то при графическом представлении сети число N выписывается рядом с короткой чертой, пересекающей дугу. Дуги с кратностью 1 не помечаются. Каждой позиции p
N (пометка позиции).Формально работа сети Петри описывается множеством последовательностей срабатываний и множеством реализуемых разметок позиций.
Для сетей Петри существует удобная алгебраическая нотация. Каждому переходу ставится в соответствие правило грамматики. Каждое правило специфицирует входную и выходную позиции. Текущее состояние сети Петри характеризуется неупорядоченным набором позиций. Каждая позиция присутствует в этом наборе столько раз, сколько меток она имеет.
