Тема
Автоматизация безопасности
В фасете «Тема» значение «Автоматизация безопасности» объединяет статьи по конкретной теме или предмету наблюдения. Здесь собраны связанные публикации, источники, участники рынка и последствия для инфраструктуры. Страница помогает сравнить повторяющиеся сигналы, затронутые организации, непрерывность услуг, закупки, конкуренцию, соблюдение требований и вопросы стратегического планирования, а также понять, почему тема важна операторам, заказчикам, инвесторам и специалистам по политике.
Истории
Лаборатории маршрутизации LACNIC нужен отчет о практическом результате
Два опроса участников мероприятий LACNIC фиксируют, кто сообщил об участии в лаборатории по безопасности маршрутизации. В новой сессии предлагается перейти от ручной проверки объявлений BGP к автоматизации RPKI. Однако ни один из этих документов не показывает, вышел ли этот…
Национальные операторы связи: тенденции Азиатско-Тихоокеанского региона
Борьба Индии с телефонным мошенничеством упирается в границу сетей
Индия заявила о готовности участвовать в предложенном ITU совместном испытании аутентификации вызывающей линии. Главный вопрос — сохранится ли доверие к номеру после прохождения звонка через операторов и страны с разными правилами.
Истории
Два сигнала APNIC о корневом ключе измеряют разное
С 11 октября корневая зона DNS должна начать подписываться ключом KSK-2024. В последних измерениях APNIC рядом с этой датой стоят два процента: один основан на сигналах от резолверов, другой — на тестах конечных систем за проверяющими DNSSEC резолверами. У этих показателей разные…
Учёные
Paul Vixie и RRL в DNS: ограничение ответов не устанавливает отправителя
Response Rate Limiting (RRL) призван ограничивать ответы авторитетного DNS-сервера при отражённой атаке с подменой адреса источника. Он может сократить число повторяющихся ответов, но не проверяет личность отправителя запроса, не устанавливает его мотив и не доказывает, что все…
IETF
Успешная настройка ещё не решала вопрос сетевого доступа: RFC 5422
RFC 5422 отделяет настройку учётных данных от разрешения доступа; режим без аутентификации сервера предназначен только для настройки.
История
Описать уязвимость — не значит опубликовать код червя: спор о раскрытии в RFC 1135
После интернет-червя 1988 года вопрос нередко сводили к выбору между публикацией и сокрытием. Современные событиям документы показывают более конкретные решения: описать уязвимость, объяснить методы программы, распространить исправление или открыть декомпилированный код, который…
IETF
AAA подтвердила абонента. Домашнему агенту всё ещё требовался ключ: RFC 5419
RFC 5419 объясняет, почему некоторые операторы Mobile IPv6 хотели использовать уже существующую связь с AAA для проверки абонентов. Но главная задача возникает после проверки: домашняя AAA-система может узнать абонента, а выбранному домашнему агенту всё равно нужна пригодная и…
IETF
Аутентификация CAPWAP-канала не разрешает устройство в сети: RFC 5418
RFC 5418 разделяет аутентификацию WTP–AC, регистрацию устройства в конкретной сети, назначение роли и маршрут клиентских данных. Успешная сессия отвечает лишь на часть операционного вопроса.
IETF
Ещё до поиска CAPWAP DHCP задавал порядок контроллеров для точки доступа: RFC 5417
Опция DHCPv4 или DHCPv6 может поставить один контроллер доступа перед другим в начальном поиске точки беспроводного завершения. RFC 5417 определяет этот порядок как настроенное предпочтение; обнаружение и DTLS позднее устанавливают, с каким узлом можно создать управляющую сессию.
IETF
RFC 5416: привязка 802.11 имеет границу поколения
RFC 5416 задаёт привязку CAPWAP для IEEE 802.11, а не универсальную гарантию всех современных возможностей Wi‑Fi. В нём описаны станции, радиопараметры, QoS и соответствие BSSID и WLAN в рамках базы 802.11-2007. Для руководителя важно отделять сообщение протокола от реально…
IETF
Состояние CAPWAP — не доказательство сервиса: RFC 5415
RFC 5415 организует WLAN control plane: Access Controller управляет Wireless Termination Points, защищает сессии, меняет конфигурацию и переносит данные. Но завершённое состояние, успешный DTLS или пакет в data channel доказывают лишь путь протокола, а не применённую политику…
IETF
WiCoP — историческая запись управления, а не база развёртывания: RFC 5414
RFC 5414 описывает WiCoP для централизованного управления и подготовки крупных WLAN. RFC Editor относит документ к Historic и указывает RFC 5415 как последующую CAPWAP-опору. Поэтому доступный контроллер или подтверждение конфигурации не доказывают актуальную авторизацию…
IETF
Безопасность SLAPP — историческая граница, а не доказательство развёртывания
RFC 5413 фиксирует Secure Light Access Point Protocol в виде, представленном работе CAPWAP. Идеи обнаружения, аутентификации и защищённого транспорта полезны как историческое свидетельство, но RFC Editor опубликовал документ для исторической записи и не рекомендует использовать…
IETF
LWAPP — историческая запись, а не основа развёртывания
RFC 5412 фиксирует Lightweight Access Point Protocol в том виде, в каком он был представлен работе CAPWAP. Он показывает архитектуру контроллера и лёгких точек доступа, но RFC Editor помечает документ как Historic и прямо запрещает использовать его как основу развёртывания. RFC…
IETF
Руководство по SIP — это карта, а не сертификат развёртывания
RFC 5411 делает обширное семейство SIP обозримым: группирует спецификации по темам, показывает статус документов и ведёт к связанным работам. Но это информационный снимок, привязанный к дате, а не живой реестр того, что реально выполняет оператор. Запись может быть…
IETF
Расширение передало сообщение о ключе. Установку ключа оно не доказало.
RFC 5410 добавляет в MIKEY расширение для OMA BCAST 1.0. Оно переносит STKM, LTKM, отчёт LTKM и сообщения родительского контроля. Полученный Type 5 подтверждает формат, но не установку ключа, активацию контекста или разрешённое воспроизведение.
IETF
CMS упаковал ключ, но идентичность получателя всё равно должна совпасть
RFC 5409 описывает BF и BB1 в CMS: они шифруют ключ содержимого, задают кодирование идентичности получателя и OID алгоритма. Открытый конверт не является разрешением на действие.
IETF
Идентичность может стать открытым ключом. Разрешением она не становится.
Шифрование на основе идентичности позволяет отправителю вычислить открытый ключ из идентификатора получателя и публичных параметров. Генератор закрытых ключей (PKG) выдаёт секрет, когда получатель обращается за ним. RFC 5408 формализует этот маршрут, но не смешивает выдачу ключа…
IETF
Канал был привязан, но операция оставалась отдельным решением.
An SIP gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5407 draws a harder line: SIP Version 2 can bind a SIP message to lower-channel information, but the binding does not become local…
IETF
Канал был привязан, но операция оставалась отдельным решением.
An IPsec gateway showed a verified security context and a clean message check. The dashboard promoted that evidence into “authorised and complete.” RFC 5406 draws a harder line: IPsec Version 2 can bind a IPsec message to lower-channel information, but the binding does not become…