Кратко

  • Передатчик выставлял SRC, когда 32-битный адрес FROM годился как TO для ответа. Любой промежуточный адаптер мог снять бит, если перестановка адресов больше не вела к исходному процессу.
  • Сохранившийся SRC подтверждал только возврат к процессу-отправителю. Контрольная сумма, выбор протокольного сервера, физическая охрана, личность инициатора и право выполнить запрос оставались независимыми вопросами.

Опубликованная в феврале 1988 года RFC 1044 описывала перенос IP и сопутствующих протоколов по оборудованию Network Systems HYPERchannel. Она закрепляла уже сложившийся 16-битный формат, вводила совместимый 32-битный, регистрировала типы сообщений и намечала переход от локальных таблиц к ARP-серверам и будущему широковещательному разрешению адресов. Но особенно ценен документ прямым указанием на то, чего принимающий IP-драйвер делать с новым признаком пока не должен был.

FROM обслуживал возврат, а не прямую доставку

В базовом сообщении TO выбирал получателя. Поле FROM шло рядом, чтобы получатель смог отправить ответ; сеть не пользовалась им для доставки исходного сообщения. Для 16-битной адресации перестановка адресов и масок магистрали обычно должна была надёжно вернуть сообщение отправителю.

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

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

SRC переносил отзывное утверждение маршрута

В расширенном заголовке появились координаты домена и сети и три флага. GNA обозначал расширенную форму адреса. CRC запрашивал или отражал сквозную проверку целостности оснащёнными адаптерами. SRC утверждал, что указанный источник пригоден для движения в обратную сторону.

Передающий хост должен был сначала постараться записать полный правильный FROM интерфейса, а затем мог установить SRC. Каждый адаптер по пути имел право погасить бит, если этот адрес в роли TO не доставил бы перевёрнутое сообщение процессу-источнику. До приёмника доходил остаток последовательности возможных возражений.

Это не цепочка подписей и не коллективное удостоверение личности. Исходное утверждение пишет сам отправитель, а путь может его отозвать по узкому техническому основанию. Уцелевший бит означает, что участвовавшие устройства не обнаружили именно дефект обратной доставки в рамках своей реализации. Он ничего не говорит о намерении пользователя.

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

«Правильный источник» получил узкое определение

RFC 1044 объясняет правильность не репутацией и не владением ключом, а результатом: после обмена TO и FROM сообщение приходит процессу, породившему исходное сообщение. Это проверяемое продолжение диалога внутри системы доставки HYPERchannel.

Однако процесс-источник не обязательно является полномочным субъектом. Машина может находиться за своим законным физическим адресом и выполнять изменённый код. Ответ может безошибочно вернуться к вредоносному запросу. Возвратность отвечает на вопрос о месте ответа, а авторизация — на вопрос о допустимости последствия.

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

CRC не превращал целостность в полномочие

Отдельный флаг CRC показывал другую плоскость контроля. Поддерживающие его адаптеры могли добавлять и проверять 32-битную контрольную сумму, защищая сетевое сообщение на проходе через промежуточные сети и аппаратуру. Успех свидетельствовал об отсутствии обнаруженной порчи переданных битов.

CRC не делал FROM обратимым, а SRC не проверял данные. Ни один флаг не устанавливал человеческую личность, не подтверждал законность IP-источника и не разрешал прикладную операцию. Запись «проверено» без названия механизма смешивает адресный маршрут, содержимое, выбор сервера и решение приложения.

Вложенный IPv4-заголовок из RFC 791 имел собственные адреса источника и назначения, протокол, полную длину и контрольную сумму заголовка. Заголовок HYPERchannel нёс другие координаты и признаки. Совпадение IP-источника с разрешённым FROM может быть полезным наблюдением, но согласованные поля ещё не создают авторизованного участника.

Разрешение адреса оставляло отдельный след происхождения

RFC 1044 описывает смену способов сопоставления: от использования младших разрядов и локальных конфигурационных файлов к известному ARP-серверу, а затем к ожидаемому распределённому широковещательному режиму. Общая форма сопоставления протокольного адреса с канальным пришла из RFC 826.

Такое разрешение определяет заголовок HYPERchannel для доставки IP-дейтаграммы локальному узлу или следующему шлюзу. Оно не доказывает, кто управляет адресом и насколько свеж ответ. Статическая строка, ответ централизованного сервера и широковещательный ответ имеют разное происхождение и должны проверяться по-разному.

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

Получателю предписали не превращать бит в барьер

Передающим IP-драйверам RFC 1044 рекомендовала выставлять Source Address Correct после попытки указать полный правильный FROM своего интерфейса. Принимающим IP-драйверам в то же время предписывалось не предпринимать по этому биту никаких действий. Требовалось дополнительное исследование поведения при отсутствии признака во время настоящего или предполагаемого нарушения безопасности.

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

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

Источники и пределы доказательства

RFC 1044 задаёт форматы сообщений, разворот адресов, выбор сервера, значения флагов, физическую предпосылку безопасности, рекомендации драйверам и этапы разрешения адресов. RFC 791 определяет независимые поля IPv4. RFC 826 определяет общий механизм сопоставления протокольного и канального адресов.

Эти документы доказывают содержание стандартов и заявленные допущения. Они не доказывают внедрение SRC на конкретной площадке, правильность каждого снятия флага, защищённость физической границы, полномочия конкретного человека или успешный результат запрошенной операции.