ОБЛАСТЬ ТЕХНИКИ
Настоящая заявка в целом относится к системе беспроводной связи, а конкретнее относится к защите сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи.
УРОВЕНЬ ТЕХНИКИ
Обслуживающий пользователя домен сети включает в себя оборудование базовой сети и функции, которые являются локальными по отношению к точке доступа пользователя. Домашний домен сети пользователя включает в себя оборудование базовой сети и функции, которые не зависят от местоположения точки доступа пользователя. Домашний домен сети пользователя может, например, управлять информацией о подписке пользователя и/или домашними услугами. Когда обслуживающий пользователя домен сети отличается от домашнего домена сети пользователя, обслуживающей домен сети и домашний домен сети осуществляют связь друг с другом, например, на предмет аутентификации пользователя, индивидуальных для пользователя данных/услуг и т. п. В этих и других случаях связь между разными доменами базовой сети следует защищать (например, с помощью защиты конфиденциальности и/или целостности) для гарантии, что связь не проверяется или не изменяется несанкционированными участниками.
Некоторые обстоятельства усложняют защиту связи между доменами. Во-первых, поставщику межсетевого обмена, который поддерживает взаимосвязь между разными доменами базовой сети, фактически может потребоваться считывать и/или изменять некоторую часть связи, чтобы предлагать операторам сети некоторые полезные услуги. Во-вторых, обеспечение надлежащей защиты связи между доменами в условиях развивающихся форматов связи чревато непрактичными административными и эксплуатационными расходами.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Некоторые варианты осуществления в этом документе используют некую политику защиты для обеспечения безопасности между доменами для сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи. Эта политика защиты может указывать, к какой одной или нескольким частям сообщения нужно применять или удалять обеспечение безопасности между доменами, например, так, что защиту можно применять или удалять выборочно только к некоторым частям сообщения. Фактически, в некоторых вариантах осуществления политика защиты включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами. Таким образом, защиту можно применять или удалять выборочно к некоторой части (частям) содержимого данного поля, а не к содержимому поля целиком.
В качестве альтернативы или дополнительно в некоторых вариантах осуществления политика защиты для обеспечения безопасности между доменами для сообщения может динамически приниматься и/или обновляться. Например, в одном варианте осуществления политика защиты, применимая к некоторому сообщению (например, определенного типа), может динамически обнаруживаться и/или извлекаться в ответ на прием этого сообщения. В другом варианте осуществления политика защиты, применимая к некоторому сообщению, может включаться или иным образом ассоциироваться с самим сообщением.
Выборочное обеспечение безопасности между доменами для некоторых частей сообщения (например, одной или нескольких частей содержимого некоторого поля) в соответствии с некоторыми вариантами осуществления в этом документе преимущественно может дать поставщику межсетевого обмена возможность считывать и/или изменять сообщение при необходимости, чтобы предлагать услуги операторам сети. В качестве альтернативы или дополнительно, динамический прием и/или обновляемость политики защиты в соответствии с некоторыми вариантами осуществления преимущественно может обеспечить гибкую защиту, которая совершенствуется вместе с изменениями форматирования сообщения (например, приписываемыми развитию сетевых функций в базовой сети), наряду с минимизацией или по меньшей мере снижением административных и эксплуатационных расходов, которые в противном случае потребовались бы для такой гибкости.
Конкретнее, варианты осуществления в этом документе включают в себя способ, выполняемый сетевым оборудованием в одном из нескольких разных доменов базовой сети в системе беспроводной связи. Способ может содержать прием сообщения, которое передано или должно быть передано между разными доменами базовой сети. Способ также может содержать применение обеспечения безопасности между доменами или удаление обеспечения безопасности между доменами из одной или нескольких частей сообщения (например, одной или нескольких частей содержимого некоторого поля в сообщении) в соответствии с политикой защиты. В некоторых вариантах осуществления политика защиты указывает, к какой одной или нескольким частям сообщения нужно применять или удалять обеспечение безопасности между доменами. Например, в одном варианте осуществления политика защиты включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами. В некоторых вариантах осуществления сетевое оборудование может получать политику защиты путем приема политики защиты, например, динамически в ответ на запрос обнаружения. В некоторых вариантах осуществления способ дополнительно содержит перенаправление сообщения адресату сообщения с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
В некоторых вариантах осуществления сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP. Например, в некоторых вариантах осуществления сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
В некоторых вариантах осуществления информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей. В качестве альтернативы или дополнительно в некоторых вариантах осуществления информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
В некоторых вариантах осуществления политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей. В этом случае для каждой из одной или нескольких частей тип применяемого или удаляемого обеспечения безопасности между доменами может содержать защиту конфиденциальности и/или защиту целостности.
В некоторых вариантах осуществления политика защиты включается в сообщение. В этих и других вариантах осуществления способ может дополнительно содержать прием политики защиты от сетевого оборудования по пути, который проходит сообщение от источника сообщения до адресата сообщения. В других вариантах осуществления способ может дополнительно содержать передачу в функцию репозитория сети, NRF, запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, в ответ на прием сообщения и прием политики защиты в ответ на запрос обнаружения.
Варианты осуществления в этом документе также включают в себя способ, выполняемый сетевым оборудованием для упрощения защиты сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи. Способ может содержать получение политики защиты. В некоторых вариантах осуществления политика защиты указывает, к какой одной или нескольким частям сообщения нужно применять или удалять обеспечение безопасности между доменами. Например, в одном варианте осуществления политика защиты включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами. Независимо от этого способ также может содержать передачу политики защиты. Например, в некоторых вариантах осуществления способ содержит передачу политики защиты сетевому оборудованию в одном из других доменов базовой сети, сконфигурированному для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты.
В некоторых вариантах осуществления способ выполняется сетевым оборудованием, которое реализует функцию репозитория сети, NRF. В этом случае способ может дополнительно содержать прием запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и передачу политики защиты в ответ на запрос обнаружения. В других вариантах осуществления способ может выполняться сетевым оборудованием по пути, который проходит сообщение от источника сообщения до адресата сообщения. В этих и других вариантах осуществления политика защиты может включаться в сообщение.
В некоторых вариантах осуществления сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP. Например, в некоторых вариантах осуществления сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
В некоторых вариантах осуществления информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей. В качестве альтернативы или дополнительно в некоторых вариантах осуществления информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
В некоторых вариантах осуществления политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей. В этом случае для каждой из одной или нескольких частей тип применяемого или удаляемого обеспечения безопасности между доменами может содержать защиту конфиденциальности и/или защиту целостности.
Варианты осуществления в этом документе также включают в себя соответствующее устройство, компьютерные программы и носители (например, постоянные машиночитаемые носители). Например, варианты осуществления в этом документе также включают в себя сетевое оборудование, сконфигурированное для использования в одном из нескольких разных доменов базовой сети в системе беспроводной связи. Сетевое оборудование содержит схемы связи и схемы обработки. Схемы обработки могут конфигурироваться для приема посредством схем связи сообщения, которое передано или должно быть передано между разными доменами базовой сети. Схемы обработки также могут конфигурироваться для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей содержимого некоторого поля в сообщении в соответствии с политикой защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого нужно применять или удалять обеспечение безопасности между доменами. Схемы обработки могут дополнительно конфигурироваться для перенаправления сообщения адресату сообщения посредством схем связи с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
Варианты осуществления дополнительно включают в себя сетевое оборудование, содержащее схемы связи и схемы обработки. Схемы обработки конфигурируются для получения политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами, где сообщение нужно передать между разными доменами базовой сети в системе беспроводной связи. Схемы обработки также конфигурируются для передачи политики защиты посредством схем связи.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг. 1 - блок-схема системы беспроводной связи в соответствии с некоторыми вариантами осуществления.
Фиг. 2A - блок-схема поля в сообщении, к которому применяется обеспечение безопасности между доменами в соответствии с некоторыми вариантами осуществления.
Фиг. 2B - блок-схема примерного содержимого поля в сообщении, к которому применяется обеспечение безопасности между доменами в соответствии с некоторыми вариантами осуществления.
Фиг. 3 - схема прохождения вызова в процессе, чтобы один или несколько посредников получили политику защиты в соответствии с некоторыми вариантами осуществления.
Фиг. 4 - схема прохождения вызова в процессе, чтобы один или несколько посредников получили политику защиты в соответствии с другими вариантами осуществления.
Фиг. 5 - логическая блок-схема способа, выполняемого сетевым оборудованием в соответствии с некоторыми вариантами осуществления.
Фиг. 6 - логическая блок-схема способа, выполняемого сетевым оборудованием в соответствии с другими вариантами осуществления.
Фиг. 7 - блок-схема системы беспроводной связи в соответствии с некоторыми вариантами осуществления.
Фиг. 8 - схема прохождения вызова в процессе для защиты передачи сообщения между доменами базовой сети в соответствии с некоторыми вариантами осуществления.
Фиг. 9A - блок-схема сетевого оборудования в соответствии с некоторыми вариантами осуществления.
Фиг. 9B - блок-схема сетевого оборудования в соответствии с другими вариантами осуществления.
Фиг. 10A - блок-схема сетевого оборудования в соответствии с еще одними вариантами осуществления.
Фиг. 10B - блок-схема сетевого оборудования в соответствии с еще одними вариантами осуществления.
ПОДРОБНОЕ ОПИСАНИЕ
Фиг. 1 показывает систему 10 беспроводной связи в соответствии с некоторыми вариантами осуществления. Система 10 включает в себя одну или несколько сетей 14 радиодоступа (RAN), которые соединяют беспроводные устройства 12 по беспроводной связи с одной или несколькими базовыми сетями 16 (CN), например, в одной или нескольких наземных сетях мобильной связи общего пользования (PLMN). В свою очередь, CN 16 соединяют беспроводные устройства 12 с одной или несколькими сетями 18 передачи данных, например Интернетом, коммутируемой телефонной сетью общего пользования (PSTN) и т. п.
В некоторых вариантах осуществления CN 16 построены на архитектуре на основе услуг, которая выгодно использует взаимодействия на основе услуг между сетевыми функциями (NF) CN, две из которых показаны в виде NF 20, 30. Каждую NF 20, 30 можно реализовать с помощью сетевого оборудования либо в виде элемента сети на специальных аппаратных средствах, в виде программного экземпляра, работающего на специальных аппаратных средствах, либо в виде экземпляра виртуализованной функции, созданного на подходящей платформе, например, в облачной инфраструктуре. Там, где система 10 является системой 5G, например, NF в плоскости управления могут включать в себя функцию управления доступом и мобильностью (AMF), функцию управления сеансом (SMF), функцию управления политиками (PCF), функцию сервера аутентификации (AUSF), функцию единого управления данными (UDM) и т. п.
NF может предоставлять свои услуги другим санкционированным NF, которые получают те услуги. Посредством этого NF может выступать в роли поставщика в качестве поставщика услуги (поставщик услуг NF) и/или в роли потребителя в качестве потребителя услуги (потребитель услуг NF). В одном примере NF 20 работает в качестве потребителя услуг NF для получения услуг, предоставляемых NF 30 в качестве поставщика услуг NF. Независимо от этого NF 20, 30 обмениваются связью в виде сообщений как часть того или для того, чтобы поставщик услуг NF предоставил свои услуги потребителю услуг NF. Хотя в некоторых вариантах осуществления NF 20, 30 находятся в разных PLMN. Тогда в этих и других вариантах осуществления эти сообщения нужно передать между разными доменами базовой сети.
Фиг. 1 показывает, что посредники 40, 50 упрощают обмен сообщениями между доменами. Каждый посредник 40, 50 конфигурируется в качестве посредника для соответствующего домена базовой сети. Там, где NF 20, 30 находятся в разных PLMN, посредники 40, 50 могут быть граничными посредниками (например, в виде граничных посредников обеспечения безопасности, SEPP) на границе соответствующей PLMN. Каждый посредник 40, 50 перехватывает сообщения (например, на прикладном уровне), которые входят и/или выходят из того домена, например, для проверки и/или фильтрации сообщений (например, на предмет вредоносности), для выполнения балансирования нагрузки или т. п. В некоторых вариантах осуществления посредники 40, 50 скрывают топологию своего соответствующего домена базовой сети. Посредники 40, 50 также защищают сообщения, передаваемые между доменами базовой сети.
В этой связи фиг. 1 в качестве примера показывает, что NF 20 является источником сообщения 60 (например, сообщения прикладного уровня), которое нужно передать в NF 30 как адресату сообщения 60. Когда NF 20, 30 находятся в разных доменах базовой сети, посредник 40 принимает (например, перехватывает) сообщение 60 перед тем, как сообщение 60 передается через границу домена базовой сети. Посредник 40 применяет обеспечение 70 безопасности между доменами к сообщению 60. Там, где защита 70 включает в себя защиту конфиденциальности, применение защиты 70 может, например, привлекать шифрование. В качестве альтернативы или дополнительно там, где защита 70 включает в себя защиту целостности, применение защиты 70 может предусматривать добавление контрольной суммы, кода аутентификации сообщения (MAC), подписи или другой информации для обнаружения подделки сообщения. В любом случае посредник 40 затем перенаправляет сообщение 60 с примененной защитой 70 к NF 30 как адресату 30 сообщения. Посредник 50 принимает (например, перехватывает) сообщение 60, входящее в домен базовой сети для NF 30. Посредник 50 удаляет обеспечение 70 безопасности между доменами (например, путем выполнения дешифрования и/или подтверждения и удаления контрольной суммы). Затем посредник 50 перенаправляет сообщение 60 к NF 30 как адресату 30 сообщения.
В соответствии с некоторыми вариантами осуществления обеспечение 70 безопасности между доменами применяется к одной или нескольким частям сообщения 60, например, так, что защиту можно применять выборочно только к некоторым частям сообщения 60 вместо необходимости применять ее к сообщению 60 целиком. Фактически, в некоторых вариантах осуществления защита 70 применяется к одной или нескольким частям содержимого некоторого поля 62 в сообщении 60. В этой связи поле 62 можно предопределить (например, на основе протокола, в соответствии с которым формируется сообщение 60) как обладающее содержимым некоторого типа и/или цели. В некоторых вариантах осуществления поле 62 также может называться элементом или информационным элементом. Таким образом, защиту можно применять выборочно к некоторой части (частям) содержимого данного поля, а не к содержимому поля целиком.
Фиг. 2A показывает пример. Как показано на фиг. 2A, в содержимом поля 62 есть несколько частей 62A, 62B и 62C. Все эти части могут иметь одинаковый тип и/или цель, чтобы вместе образовывать содержимое поля. Однако защита 70 можно применять выборочно к части 62B, исключив части 62A и 62C. Например, в некоторых вариантах осуществления посредник 50 извлекает часть 62B из поля 62 и применяет защиту 70 выборочно к извлеченной части 62B (например, путем выборочного шифрования части 62B и/или формирования контрольной суммы выборочно для части 62B). Части 62A и 62C могут оставаться незащищенными. В свою очередь посредник 50 при приеме сообщения 60 может извлечь часть 62B из поля 62 и удалить защиту 70 выборочно из извлеченной части 62B (например, путем выборочного дешифрования части 62B и/или подтверждения и удаления контрольной суммы для части 62B).
Фиг. 2B иллюстрирует характерный пример содержимого поля в некоторых вариантах осуществления, где сообщение 60 является сообщением протокола передачи гипертекста (HTTP), а поле 62 является полем HTTP (например, телом или частью тела сообщения HTTP, или полем в заголовке или псевдо-заголовке HTTP). Как показано, сообщение 60 является запросом GET HTTP, а поле 62 является полем PATH. Содержимым поля PATH является унифицированный идентификатор ресурса (URI) запроса. Тогда в этом случае защита 70 может применяться к одной или нескольким частям URI запроса в поле PATH. Конечно, содержимое поля PATH (а именно, URI запроса) в этом примере содержит несколько частей 62A, 62B и 62C с выборочно примененной защитой 70 только к части 62B в URI запроса. В этом примере часть 62B включает в себя идентификатор абонента в виде международного идентификатора абонента мобильной связи (IMSI). Другие части 62A и 62C могут оставаться незащищенными.
Выборочное обеспечение безопасности между доменами для некоторых частей сообщения 60 (например, одной или нескольких частей содержимого поля 62) в соответствии с некоторыми вариантами осуществления может предохранять те некоторые части от несанкционированной проверки и/или подделки, одновременно предоставляя объектам возможность считывать и/или изменять другие части. Например, поставщик межсетевого обмена, который обеспечивает соединение между разными доменами базовой сети, может при необходимости считывать и/или изменять незащищенные части, чтобы предлагать услуги операторам сети. Поэтому дробность защиты можно приспособить точно к дробности (например, уязвимого) содержимого, фактически нуждающегося в защите. Это исключает слишком широкую защиту, что создает угрозу использованию другими объектами другого содержимого и/или может увеличить без необходимости ресурсы связи или мощность обработки.
Примечательно, что некоторые варианты осуществления в этом документе используют политику 80 защиты для осуществления этого выборочного обеспечения безопасности между доменами для некоторых частей сообщения 60 (например, одной или нескольких частей содержимого поля 62). Политика 80 защиты включает в себя информацию, указывающую, к какой одной или нескольким частям сообщения 60 нужно применять обеспечение 70 безопасности между доменами (например, с помощью посредника 40) или удалять (например, с помощью посредника 50). Тогда в некоторых вариантах осуществления эта информация указывает, к какой одной или нескольким частям содержимого поля 62 нужно применять или удалять обеспечение 70 безопасности между доменами. Отметим, что информация может эффективно указывать, к какой одной или нескольким частям нужно применять/удалять защиту 70, либо явно путем указания части (частей), к которым нужно применять/удалять защиту 70, либо неявно путем указания части (частей), к которым не нужно применять/удалять защиту 70. Политика 80 защиты в одном варианте осуществления также указывает для каждой из одной или нескольких частей тип применяемого или удаляемого обеспечения 70 безопасности между доменами (например, защита конфиденциальности и/или целостности).
Например, в некоторых вариантах осуществления информация в политике 80 защиты включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей. В этой связи регулярное выражение может быть последовательностью символов, которая задает шаблон поиска. В свою очередь шаблон поиска могут использовать поисковые алгоритмы для отыскания некоторого шаблона символов в сообщении 60 (например, в содержимом поля).
Например, регулярным выражением, пригодным для отыскания части 62B на фиг. 2B (например, IMSI), может быть "^/udm-sdm/v1/([^/?#]+)/nssai$". В этом примере циркумфлекс (а именно ^) и знак доллара (а именно $) являются привязками, которые не "потребляют" никакие символы, а вместо этого связывают шаблон с началом и концом искомой строки. Символы ([^/?#]+) в регулярном выражении собирают любой подшаблон или подгруппу, которая включает в себя одно или несколько вхождений любого символа за исключением косой черты (/), вопросительного знака (?) и символа решетки (#). Этот собранный подшаблон или подгруппа выводится из поискового алгоритма. Соответственно, синтаксический анализ содержимого поля с использованием регулярного выражения даст подшаблон "imsi-214050123456789". Поэтому защиту 70 можно выборочно применять только к этому подшаблону, исключив другие части 62A и 62C содержимого поля.
Конечно, регулярное выражение при использовании в данном документе является лишь одним из способов указать некую часть. Политика 80 защиты может включать в себя любой тип выражения, шаблона, синтаксиса, языка, разделителя, указателя, правила или другую информацию, которая указывает одну или несколько частей. Например, в некоторых вариантах осуществления информация может быть любой информацией, которая указывает шаблон, маркер или подстроку внутри более широкой строки. Например, в примере из фиг. 2B информация в качестве альтернативы может указывать часть 62B как третий сегмент пути в содержимом поля; то есть подшаблон или подгруппу символов, встречающуюся между третьим и четвертым маркерами или разделителями в виде косой черты (/). В еще одних вариантах осуществления информация может включать в себя один или несколько диапазонов байтов в поле 62 и/или один или несколько диапазонов разрядов в поле 62, которые указывают одну или несколько частей.
В еще одних вариантах осуществления информация в политике 80 защиты включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей. Указатель JSON (например, который задан в RFC 6901) является синтаксисом строки для идентификации определенного значения в документе JSON. Указатель JSON может выражаться строковыми значениями JSON и/или идентификаторами фрагмента URI. Указатель JSON является, в частности, Unicode-строкой, содержащей последовательность из нуля или более опорных маркеров. Каждый маркер предваряется символом косой черты "/". Тогда в этих и других вариантах осуществления политика 80 защиты в качестве примера может указывать одну или несколько частей содержимого в теле или полезной нагрузке сообщения HTML, где это тело или полезная нагрузка включает в себя документ JSON.
Вне зависимости от конкретной сущности информации в политике 80 защиты эти примеры иллюстрируют, что политика 80 защиты в некоторых вариантах осуществления указывает часть (части) (к которым нужно применять или удалять защиту 70) с помощью информации, которая нейтральна, не зависит и/или в общем применима к любому из лежащего в основе содержимого сообщения/поля или протокола передачи сообщения. Например, политика 80 защиты может допускать указание любой части (частей) содержимого в поле 62 с помощью одного и того же общего вида информации (например, регулярного выражения) вне зависимости от типа, структуры или форматирования содержимого поля. То есть в одном случае информацию можно образовать (например, в виде конкретного регулярного выражения) для указания некоторой части содержимого в поле 62 на основе содержимого некоторого типа или формата (например, IMSI), но в другом случае информацию можно образовать (например, в виде другого регулярного выражения) для указания другой части содержимого в поле 62 на основе содержимого другого типа или формата (например, идентификатор соты). Но информация в обоих случаях содержит один и тот же общий символ (например, оба - регулярные выражения), чтобы дать посредникам 40, 50 универсальную возможность идентифицировать любую часть (части) без учета, развивается ли или как развивается тип, структура или формат лежащего в основе содержимого. Соответственно, конфигурирование посредников 40, 50 для общего понимания или обработки регулярных выражений или другой информации в политике 80 защиты достаточным образом оснащает посредников 40, 50 для выборочного применения или удаления защиты 70 из любой части содержимого в сообщении 60 или поле 62, даже без конфигурирования посредников 40, 50 для более точного понимания того содержимого. Тогда в примере из фиг. 2B посреднику нужно просто понимать, как обрабатывать регулярное выражение для защиты части 62B, без необходимости более точного понимания, как идентифицировать IMSI. Это означает, что посредники 40, 50 могут оставаться неосведомленными о том, как меняется или развивается лежащее в основе содержимое (например, по форме или структуре), например, в ответ на введение в систему 10 новых объектов (например, сетевых функций) и/или услуг (например, представленных их URI HTTP). Тогда в некоторых вариантах осуществления именно информация в политике 80 защиты (например, регулярные выражения) динамически меняется или развивается для учета изменений или развития лежащего в основе содержимого сообщения 60 (например, в плане структуры или формата), а не общая конфигурация посредников для идентификации части (частей) с использованием того вида информации.
В качестве альтернативы или дополнения к вышеупомянутым вариантам осуществления политика 80 защиты для обеспечения 70 безопасности между доменами для сообщения 60 может приниматься и/или обновляться динамически посредником 40 или 50. Динамическое извлечение и/или обновление политики 80 может учитывать изменения или развитие содержимого сообщения 60. Таким образом, конфигурацию самого посредника 40 или 50 не нужно (вручную) обновлять для учета такого изменения или развития. В соответствии с некоторыми вариантами осуществления это может обеспечить преимущественно гибкую защиту, которая совершенствуется вместе с изменениями форматирования сообщения (например, приписываемыми развитию сетевых функций или услуги в базовой сети), наряду с минимизацией или по меньшей мере снижением административных и эксплуатационных расходов, которые в противном случае потребовались бы для такой гибкости.
Фиг. 3 иллюстрирует, например, некоторые варианты осуществления, где посредник 40 и/или 50 динамически обнаруживает политику 80 защиты от одной или нескольких функций 90 репозитория сети (NRF), например, в ответ на прием сообщения 60. Как показано, NF 20 в качестве источника сообщения 60 передает сообщение 60, которое перехватывается или иным образом принимается посредником 40 (этап 1). В ответ на прием сообщения 60 посредник 40 передает услуге обнаружения (в ее домене базовой сети) запрос 92 обнаружения, запрашивающий обнаружение политики 80 защиты для защиты сообщения 60 (этап 2). Услуга обнаружения показана здесь как реализуемая функцией 90A репозитория сети, NRF, но в других вариантах осуществления ее можно реализовать с помощью автономной функции, совмещенной с NRF, или с помощью другого сетевого оборудования или функций. Независимо от этого посредник 40 принимает политику 80 защиты в ответ на запрос обнаружения (этап 3). Посредник 40 применяет защиту к одной или нескольким частям сообщения 60 (например, одной или нескольким частям содержимого поля 62), определенным в соответствии с политикой 80 защиты, и передает защищенное сообщение 60 посреднику 50 через границу домена базовой сети (этап 4). В ответ на прием сообщения 60 посредник 50, в свою очередь, передает запрос 94 обнаружения услуге обнаружения (в ее домене базовой сети), показанной как реализуемой с помощью NRF 90B (этап 5). В ответ на запрос обнаружения посредник 50 принимает политику 80 защиты от услуги обнаружения (этап 6). Посредник 50 удаляет защиту из одной или нескольких частей сообщения 60 (например, одной или нескольких частей содержимого поля 62), определенных в соответствии с политикой 80 защиты, и передает (незащищенное) сообщение 60 в NF 30 как адресату сообщения (этап 7).
Хотя и не показано, в некоторых вариантах осуществления источник и/или адресат сообщения предоставляет политику 80 защиты, применимую к сообщению 60, услуге обнаружения в одном или нескольких доменах базовой сети, например, для последующего обнаружения той политики 80, как показано на фиг. 3. Например, там, где NF 30 является NF поставщика, которая предоставляет услугу NF 20 как NF потребителя, и сообщение 60 является сообщением, которое NF 20 отправляет к NF 30 для получения той услуги, в некоторых вариантах осуществления NF 30 в качестве NF поставщика предоставляет NRF 90B свой профиль услуги (например, как часть начальной регистрации или обновления регистрации), включающий политику 80 защиты, применимую к одному или нескольким сообщениям, используемым для получения услуги, предоставляемой NF 30. В свою очередь NRF 90B может распространять или иным образом предоставлять NRF 90A профиль услуги или по меньшей мере политику 80 защиты для последующего обнаружения возможными NF потребителя.
Хотя в еще одних вариантах осуществления посредник 40 и/или 50 может подписаться для оперативного приема новых или обновленных политик защиты от NRF 90A и/или 90B. В этих и других вариантах осуществления посредник 40 и/или 50 может хранить (например, кэшировать) принятые политики защиты в ожидании последующего использования для защиты сообщений, передаваемых между доменами базовой сети.
В отличие от этого фиг. 4 показывает другие варианты осуществления, где посредник 40 и/или 50 принимает политику 80 защиты от сетевых функций или оборудования по пути, который проходит сообщение 60 от источника до адресата сообщения 60. В частности, фиг. 4 показывает, что NF 20 в качестве источника сообщения передает сообщение 60 со встроенной или иным образом включенной в сообщение 60 (например, в заголовок сообщения) политикой 80 защиты (этап 1). Таким образом, посредник 40 принимает политику 80 защиты от источника сообщения 60. Затем посредник 40 передает защищенное сообщение 60 через границу домена базовой сети снова с включенной в сообщение 60 политикой 80 защиты (этап 2). Посредник 50 соответственно принимает политику 80 защиты от посредника 40 в другом домене базовой сети. Затем посредник 50 может удалить защиту сообщения 60 и перенаправить его к NF 30 как адресату (этап 3).
В связи с вышеупомянутыми изменениями и модификациями сетевое оборудование в некоторых вариантах осуществления выполняет, как правило, показанный на фиг. 5 способ 100. Сетевое оборудование может конфигурироваться в качестве посредника для одного из нескольких разных доменов базовой сети в системе 10 беспроводной связи. Например, способ 100 может выполняться сетевым оборудованием, сконфигурированным в качестве посредника 40 или посредника 50. Как показано, способ 100 включает в себя прием сообщения 60, которое передано или должно быть передано между разными доменами базовой сети (этап 110). Способ 100 также может включать в себя прием политики 80 защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям сообщения 60 (например, одной или нескольким частям содержимого поля 62 в сообщении 60) нужно применять или удалять обеспечение 70 безопасности между доменами (этап 120). Способ 100 может дополнительно включать в себя применение обеспечения безопасности между доменами или удаление обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой 80 защиты (этап 130). В некоторых вариантах осуществления способ 100 также может включать в себя перенаправление сообщения 60 адресату сообщения 60 с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами (этап 140).
В некоторых вариантах осуществления способ дополнительно содержит передачу в функцию репозитория сети, NRF, запроса обнаружения, запрашивающего обнаружение политики 80 защиты для защиты сообщения 60, в ответ на прием сообщения 60 и прием политики защиты в ответ на запрос обнаружения. В качестве альтернативы способ может содержать прием политики 80 защиты от сетевого оборудования по пути, который проходит сообщение от источника сообщения до адресата сообщения.
Также в связи с вышеупомянутыми изменениями и модификациями сетевое оборудование в других вариантах осуществления выполняет, как правило, показанный на фиг. 6 способ 200 для упрощения защиты сообщения 60, передаваемого между разными доменами базовой сети в системе 10 беспроводной связи. Способ 200 может выполняться, например, сетевым оборудованием, реализующим NF 20, посредника 40, посредника 50, NF 30 или NRF 90. Как показано в этой связи, способ 200 включает в себя получение политики 80 защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям сообщения 60 (например, одной или нескольким частям содержимого поля 62 в сообщении 60) нужно применять или удалять обеспечение 70 безопасности между доменами (этап 210). Способ 200 также может включать в себя передачу политики 80 защиты (этап 220).
Например, в некоторых вариантах осуществления передача политики защиты содержит передачу политики защиты сетевому оборудованию, сконфигурированному в качестве посредника для одного из других доменов базовой сети, для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты.
В качестве альтернативы или дополнительно способ может выполняться сетевым оборудованием, которое реализует функцию репозитория сети, NRF, и может дополнительно содержать прием запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и передачу политики защиты в ответ на запрос обнаружения.
В качестве альтернативы способ может выполняться сетевым оборудованием по пути, который проходит сообщение от источника сообщения до адресата сообщения (например, с помощью NF 20, посредника 40, посредника 50 или NF 30).
Сейчас будут обсуждаться некоторые варианты осуществления с их значимостью для применения к 5G.
3GPP работает над 5G и ассоциированной базовой сетью (5GC), которая предоставляет услуги подключающимся пользователям, от аутентификации до присваивания IP-адреса и маршрутизации пакетов. Однако базовая сеть 5G значительно отличается от предыдущего поколения.
Одним из изменений в архитектуре 5G является реализация так называемой архитектуры на основе услуг (SBA). В этой новой архитектуре некоторое количество интерфейсов в базовой сети (включая интерфейсы роуминга) меняется с унаследованных телекоммуникационных на современные, основанные на Интернет-технологии интерфейсы прикладного программирования (API). Над подробностями этих API в настоящее время работает группа SA2 в 3GPP, в документе 23.501 и 23.502 по архитектуре базовой сети 5G, а также группы CT 3GPP.
Есть несколько альтернатив по разработке и реализации архитектуры на основе услуг. Среди нескольких возможностей группа CT4 3GPP выбрала архитектуру на основе архитектурной модели передачи состояния представления (REST). В этой модели разные объекты (услуги, сетевые функции и т. п.) в системе 5G взаимодействуют друг с другом путем вызова действий на так называемом "ресурсе", который идентифицируется в HTTP по унифицированному идентификатору ресурса (URI). Тогда разные действия для вызова в разных объектах системы задаются разными стандартными командами HTTP (например, GET, POST, PUT, DELETE и т. п.), тогда как сообщения HTTP переносят представления затрагиваемых ресурсов в полезной нагрузке HTTP. Эти представления можно форматировать на разных языках кодирования данных (например, JSON).
Базовая сеть 5G может придерживаться этих требований: основной протокол: HTTP/2; транспортный протокол: TCP; исполнение API в стиле REST; формат упорядочения данных: JSON; инициируемые сервером взаимодействия: "веб-перехват"; и язык определения интерфейсов: OpenAPI 3.0.0 (известный раньше как "Swagger").
Разные сетевые функции в базовой сети 5G предоставляют свои услуги через интерфейс прикладного программирования (API). Этот API задает ресурсы HTTP (унифицированные идентификаторы ресурсов, URI), разрешенные операции (GET, POST, PUT, …) и формат данных, переносимых в полезной нагрузке сообщения (тело сообщения).
Пока информация о поставщиках услуг NF не сконфигурируется локально в соответствующих потребителях услуг NF (это может происходить, если предполагаемая услуга NF или NF находится в той же PLMN, что и NF инициатора запроса), потребители услуг NF обнаруживают и выбирают поставщиков услуг NF динамически с использованием функции репозитория сети, NRF. NRF - логическая функция, которая используется для ведения профиля NF доступных экземпляров поставщиков услуг NF и их поддерживаемых услуг, приема запросов обнаружения услуг NF от потребителей услуг NF и предоставления информации о доступных экземплярах соответствующих поставщиков услуг NF запрашивающему потребителю услуг NF.
Чтобы обеспечить доступ к запрошенному типу NF или услуге NF, NF инициатора запроса инициирует обнаружение NF или услуги NF путем предоставления в NRF типа NF или определенной услуги, которую пытается обнаружить (например, функция управления сеансом, SMF, функция политики тарификации, PCF, сообщение о местоположении пользовательского оборудования, UE), и других параметров услуги (например, связанной с сегментацией информации). В зависимости от выбранной модели маршрутизации сообщений NRF может предоставить NF инициатора запроса IP-адрес или полностью определенное доменное имя (FQDN) либо идентификатор релевантных услуг и/или экземпляра (экземпляров) NF. NF инициатора запроса на основе той информации может выбрать один определенный экземпляр NF или экземпляр NF, который способен предоставить конкретную услугу NF (например, экземпляр PCF, который может обеспечить авторизацию политик).
В случаях роуминга (то есть когда пользователь обращается к сети помимо его или ее домашней сети, где у пользователя есть подписка), связь между гостевой сетью и домашней сетью можно защищать (например, криптографически) для гарантии, что отправленная по связующим сетям информация не проверяется или не изменяется несанкционированными участниками. Эта задача выполняется элементом сети, называемым SEPP (граничный посредник обеспечения безопасности). Здесь могут быть vSEPP (SEPP в гостевой сети) и hSEPP (SEPP в домашней сети), которые осуществляют связь по интерфейсу N32.
Защита связи между SEPP может происходить на прикладном уровне. В некоторых вариантах осуществления защита целостности применяется ко всем атрибутам, переносимым по интерфейсу N32. В качестве альтернативы или дополнительно конфиденциальность одного или нескольких следующих атрибутов можно защитить при отправке по интерфейсу N32: векторы аутентификации; криптографический материал; данные местоположения, например ID соты и ID физической соты; или постоянный идентификатор абонента (SUPI), например Международный идентификатор абонента мобильной связи (IMSI).
Как часть функций SEPP одна из них предназначена для защиты информации, отправляемой в разных полях, которые составляют сообщения HTTP. Этими полями HTTP могут быть, например, URI запроса HTTP, заголовки HTTP и разные части тела HTTP (или полезной нагрузки).
Соединение между двумя PLMN обычно выполняется так называемыми поставщиками IPX. Кроме фактического соединения, поставщики IPX также обычно предлагают операторам дополнительные услуги. Некоторые из этих услуг основываются на считывании и/или изменении полей в сообщениях, отправляемых между PLMN. Поэтому желательно, чтобы некоторые части или поля сообщения фактически не защищались криптографически при отправке по интерфейсу N32 между vSEPP и hSEPP.
Подводя итог, SEPP должен защищать (шифровать и/или защищать целостность) некоторые информационные поля или части в сообщениях, отправляемых по N32, а некоторые другие части сообщений SEPP должен оставить незащищенными, например, для осуществления дополнительных услуг, предоставляемых поставщиками IPX.
Однако, если по N32 отправляется новый тип сообщения, который не задавался при развертывании или последнем обновлении SEPP, то части сообщения, которые нужно защищать, явно не известны SEPP. Еще желательно, чтобы SEPP мог предоставлять свои услуги без необходимости обновления программного обеспечения в результате обычного функционального развития разных сетевых функций в базовой сети.
Некоторые варианты осуществления в этом документе преимущественно предоставляют политику, которая задает, какие части сообщения нужно защищать, и каким способом их необходимо защищать (конфиденциальность, целостность). В одном или нескольких вариантах осуществления эта политика выражается на некотором языке или "маске", которая применима (сопоставление с шаблоном) к новым типам сообщений. Таким образом, политику можно выражать динамически, и ее не нужно знать при развертывании или последнем обновлении SEPP. Варианты осуществления в этом документе также включают в себя потоки для информирования SEPP о политике, применимой к определенному сообщению. В силу этого варианты осуществления предоставляют динамический и гибкий способ выборочной защиты частей сообщений, отправляемых по N32, таким образом, что выполняющие такую защиту (шифрование и/или защиту целостности) объекты не зависят от статической конфигурация и не нуждаются в изменении, когда в систему добавляются новые объекты (сетевые функции) и новые услуги (представленные их URI HTTP).
Некоторые варианты осуществления допускают применение механизма безопасности без влияния на исполнение (API) услуг между домашней и гостевой PLMN. Дополнительно или в качестве альтернативы некоторые варианты осуществления допускают защиту (шифрование и/или защиту целостности) уязвимых информационных элементов (например, идентификаторов пользователей типа IMSI), обнаруживаемых в сообщениях HTTP в трафике 5G, переносимом между операторами сети, гибким способом, не связанным с текущим определением API услуг и готовым к введению новых сетевых функций, услуг и API при дальнейшем развитии базовой сети 5G.
Ниже обсуждаются два варианта для примеров потоков сигнализации для информирования SEPP о политике для определенного сообщения. Фиг. 7 показывает примерный контекст для обсуждения вариантов 1 и 2.
В варианте 1 SEPP запрашивает у NRF информацию о применимой политике защиты. Как показано, сетевая функция NF1 в PLMN1 намеревается отправить сообщение сетевой функции NF2 в PLMN2. Сообщение направляется через SEPP1 и SEPP2 в PLMN1 и PLMN2. Когда SEPP1 принимает это сообщение, он проверяет, сохранил ли политику защиты для этого типа сообщения, которая еще не истекла. Если такая политика защиты не доступна, то SEPP1 запрашивает у NRF в PLMN1 (называемой NRF1).
Если SEPP1 запросила у NRF1 политики защиты, применимые к определенному сообщению, то NRF1 отправляет SEPP1 доступные политики защиты. NRF1 может понадобиться запросить у NRF2, NRF в PLMN2. NRF1 может принять политики защиты от NF1 при регистрации. NRF2 может принять политики защиты от NF2 при регистрации.
Перед перенаправлением сообщения к SEPP2 SEPP1 выполняет защиту сообщения (например, криптографическую защиту) в соответствии с политикой, принятой от NRF1 и/или NRF2. SEPP1 может включить политику защиты в сообщение, которое перенаправляет. Отметим, что "перенаправляющий" SEPP может изменять сообщение или даже заключать его в другое сообщение.
При приеме сообщения от SEPP1 SEPP2 дешифрует зашифрованные части сообщения и проверяет целостность у частей сообщения с защитой целостности. SEPP2 может использовать политику защиты, принятую от SEPP1, или при необходимости запросить у NRF1 и/или NRF2 для получения информации о политике защиты.
SEPP2 перенаправляет сообщение к NF2.
В отличие от этого в варианте 2 NF, которая отправляет сообщение (NF1), включает политику защиты в сообщение. NF может принять политику во время обнаружения услуги (если она - потребитель услуги) или во время регистрации услуги (если она - поставщик услуги).
В этой связи сетевая функция NF1 выполняет обнаружение услуги или регистрацию услуги в NRF1, NRF в своей PLMN. Как часть вышеупомянутого обнаружения или регистрации NRF1 может включать политики защиты для типов сообщений, которые NF1 может отправлять при получении или предоставлении услуги. Для случая обнаружения NRF1 может принять политику защиты от NRF2.
При получении или предоставлении услуги NF1 планирует отправить сообщение к NF2. Сообщение направляется через SEPP1 и SEPP2. NF1 включает в сообщение политику защиты, которая применима для этого сообщения. NF1 может принять политику от NRF1 или NRF2, но в качестве альтернативы политика может происходить от самой NF1.
Перед перенаправлением сообщения к SEPP2 SEPP1 выполняет защиту сообщения в соответствии с политикой, принятой от NF1. Для обеспечения того, что SEPP2 способен извлекать исходное сообщение, SEPP1 может включать информацию, которая позволяет SEPP2 знать, какие части защищались. Это можно решить, например, путем включения политики защиты в сообщение, которое SEPP1 перенаправляет. Снова отметим, что "перенаправляющий" SEPP может изменять сообщение или даже заключать его в другое сообщение.
При приеме сообщения от SEPP1 SEPP2 дешифрует зашифрованные части сообщения и проверяет целостность у частей сообщения с защитой целостности. Например, SEPP2 может использовать принятую от SEPP1 политику защиты.
SEPP2 перенаправляет сообщение к NF2.
Политика защиты, как обсуждалось в этих примерах, описывает, какие элементы сообщения следует шифровать, и целостность каких элементов следует защищать. Политика может явно описывать, какие элементы следует защищать (шифровать и/или защищать целостность), или может явно описывать, какие элементы не следует защищать (не шифровать и/или не защищать целостность).
Одна из возможных реализаций политики защиты указана ниже. Политика защиты может задаваться для всех сообщений, отправляемых и принимаемых NF. Сообщения могут быть либо запросами HTTP, либо ответами HTTP.
В некоторых вариантах осуществления политика защиты содержит одной или несколько правил защиты. Каждое правило защиты состоит из: (1) типа сообщения, к которому применимо правило, включая, например, запрос HTTP, ответ HTTP или то и другое; (2) объекта сообщения, к которому применимо правило, который может быть, например, URI запроса, псевдо-заголовком HTTP, заголовком HTTP или телом HTTP; и (3) операции совпадения и замены. В зависимости от объекта сообщения операцию можно представить с помощью регулярного выражения, указателя JSON (RFC 6901) на элемент в структуре JSON и его замены, или любого другого выражения.
В некоторых вариантах осуществления правило защиты должно существовать в политике защиты для каждого элемента каждого сообщения, который требуется защищать.
При связи между двумя NF в некоторых вариантах осуществления может использоваться одна политика защиты. Эта политика защиты может задаваться NF, предоставляющей услугу (то есть вызванной NF). Политика защиты может применяться к сообщениям, отправленным и принятым NF. Политика защиты для NF может храниться в NRF, расположенной в PLMN NF, предоставляющей услугу.
Политика защиты может использоваться для связи NF с несколькими PLMN, но также можно задавать политики защиты отдельно для каждой PLMN, с которой взаимодействует NF.
Политика защиты для NF в данной PLMN может быть общей для всех потребителей услуг NF, с которыми взаимодействует NF, предоставляющая услугу.
SEPP при шифровании сообщения, отправляемого к NF, должен перебирать правила защиты в политике защиты для той NF. Для каждого правила политики, если тип сообщения в правиле совпадает с типом сообщения, то он должен применить соответствующую операцию совпадения и замены к объекту сообщения, определенному правилом.
SEPP при дешифровании сообщения, принятого от другого SEPP, должен перебирать правила защиты в политике защиты для принимающей NF. Для каждого правила политики, если тип сообщения в правиле совпадает с типом сообщения, то он должен применить обратную операцию совпадения и замены к объекту сообщения, определенному правилом.
Процесс шифрования и дешифрования завершается, когда оценены все правила защиты в политике защиты.
В зависимости от применимой разновидности применимая политика защиты может либо предоставляться SEPP (от NF или SEPP в другой PLMN), либо обнаруживаться самим SEPP в NRF.
В некоторых вариантах осуществления политика защиты может предоставляться локально относительно NF и в NRF. Для последнего случая политика защиты может регистрироваться в NRF для каждой NF. Это может выполняться посредством NF как часть ее процесса регистрации в NRF или с помощью другого механизма, например обеспечения управления и обслуживания (O&M). В обоих случаях цель - предотвратить необходимость обновления SEPP, когда разворачиваются новые NF или изменения в политике защиты у существующих NF.
Конкретный пример для варианта 2 показан на фиг. 8. В этом примере сетевой функции в гостевой PLMN (например, функция доступа и мобильности, AMF) нужно отправить запрос HTTP сетевой функции в домашней PLMN (например, функции единого управления данными, UDM) для извлечения данных подписки конкретного пользователя. Данные подписки могут быть небольшой частью профиля подписки, например, необходимыми данными для выбора конкретного "сегмента" базовой сети 5G.
Чтобы вычислить URI у UDM (которая располагается в домашней PLMN), AMF запрашивает у локальной NRF путем выдачи сообщения с запросом обнаружения. Сообщение с запросом обнаружения включает в себя критерии поиска, например необходимый тип сетевой функции (в этом случае UDM) или определенная услуга (в этом случае "nudm-sdm"). В свою очередь NRF в vPLMN перенаправляет запрос обнаружения к NRF в hPLMN, и в результате к vAMF возвращается список доступных сетевых функций UDM (конечные точки URI) в hPLMN.
Как часть возвращенных профилей доступных экземпляров UDM информация профиля включает в себя параметры, указывающие разные доступные URI в каждой услуге. Информация профиля также включает в себя политику 80 защиты, которая включает в себя информацию о том, где в этих URI находится уязвимая информация, которую нужно защищать. Рассмотрим пример:
GET http://www.homeoperator.com/nudm-sdm/v1/{SUPI}/nssai
В этом случае AMF может использовать этот URI, когда нужно извлечь вспомогательную информацию выбора сегмента сети (NSSAI) данного пользователя, сохраненную в UDM в его/ее домашней сети. В вышеприведенном синтаксисе составляющая {SUPI} представляет собой переменную, которую нужно заменить настоящим идентификатором пользователя, например:
GET http://www.homeoperator.com/nudm-sdm/v1/imsi-214050123456789/nssai
Запрос HTTP направляется от AMF к SEPP в гостевой сети (vSEPP), и AMF включает политику 80 защиты в определенный заголовок HTTP, включающий принятую от NRF информацию о частях URI, которые нужно защищать, потому что они содержат уязвимую информацию.
vSEPP принимает сообщение HTTP. vSEPP определяет SEPP в hPLMN (hSEPP), куда эту информацию нужно отправить, и проверяет релевантное соглашение о роуминге для выяснения подходящих ключей шифрования, которые нужно использовать для защиты сообщений между SEPP. vSEPP также извлекает определенный заголовок HTTP, отправленный AMF, и обрабатывает URI соответствующим образом, так что уязвимые части URI можно зашифровать с использованием найденных ключей. Заголовок HTTP может указывать, например, следующее регулярное выражение (из примера URL выше): "^/udm-sdm/v1/([^/?#]+)/nssai$". Это позволяет отыскать полное совпадение, где 1ая внутренняя группа "([^/?#]+)" является набором символов, где предполагается найти значение {supi}.
hSEPP принимает сообщение HTTP и выполняет обратную операцию. Он определяет PLMN, которая отправляет сообщение, чтобы проверить применимые соглашения о роуминге и определить правильные ключи шифрования. Затем он проверяет определенный заголовок HTTP и определяет части URI, которые подвергнуты защите (шифрованию), дешифрует их и заменяет незашифрованной версией. hSEPP также удаляет заголовок HTTP, который указывал части URI, которые были зашифрованы.
Затем hSEPP перенаправляет сообщение HTTP к экземпляру UDM в HPLMN. Это сообщение идентично сообщению, созданному vAMF, и поэтому шифрование/дешифрование некоторых составляющих URI, выполненное между SEPP, прозрачно для связи vAMF -> hUDM.
Хотя варианты осуществления проиллюстрированы в контексте передачи сообщения 60 между доменами базовой сети, которые принимают вид базовых сетей в разных PLMN, варианты осуществления в этом документе можно распространить на любой тип доменов базовой сети. Фактически, в некоторых вариантах осуществления домены базовой сети являются разными доменами в одной и той же базовой сети.
Дополнительно отметим, что варианты осуществления в этом документе могут использовать любой один или несколько протоколов связи, известных в данной области техники или которые можно разработать, например IEEE 802.xx, коллективный доступ с кодовым разделением каналов (CDMA), широкополосный CDMA (WCDMA), глобальная система мобильной связи (GSM), система долгосрочного развития (LTE), WiMax, New Radio (NR) или т. п. Соответственно, хотя в этом документе иногда описаны применительно к 5G, обсуждаемые в этом документе принципы и понятия применимы к системам 4G и другим.
Беспроводное устройство при использовании в данном документе является любым типом устройства, допускающего осуществление связи с другим радиоузлом по беспроводной связи посредством радиосигналов. Поэтому беспроводное устройство может относиться к пользовательскому оборудованию (UE), мобильной станции, переносному компьютеру, смартфону, межмашинному (M2M) устройству, устройству связи машинного типа (MTC), устройству узкополосного Интернета вещей (IoT) и т. п. Тем не менее, хотя беспроводное устройство может называться UE, следует отметить, что у беспроводного устройства не обязательно есть "пользователь" в смысле отдельного человека, владеющего и/или работающего на том устройстве. Беспроводное устройство также может называться устройством беспроводной связи, радиоустройством, устройством радиосвязи, беспроводным терминалом или просто терминалом - пока контекст не указывает иное, использование любого из этих терминов подразумевает UE или устройства между устройствами, устройства машинного типа или устройства, допускающие межмашинную связь, датчики, оборудованные беспроводным устройством, настольные компьютеры с возможностью беспроводной связи, мобильные терминалы, смартфоны, встраиваемое в переносной компьютер оборудование (LEE), устанавливаемое на переносной компьютер оборудование (LME), адаптеры USB, беспроводное оборудование в помещении абонента (CPE) и т. п. В обсуждении в этом документе также могут использоваться термины межмашинное (M2M) устройство, устройство связи машинного типа (MTC), беспроводной датчик и датчик. Следует понимать, что эти устройства могут быть UE, но в целом могут конфигурироваться для передачи и/или приема данных без прямого взаимодействия с человеком.
В сценарии IoT беспроводное устройство, которое описано в этом документе, может быть машиной либо устройством или может входить в их состав, которая (которое) выполняет контроль или измерения и передает результаты такого контроля или измерений другому устройству или сети. Конкретными примерами таких машин являются измерители мощности, промышленное оборудование или домашние либо личные приборы, например холодильники, телевизоры, личные носимые устройства, например часы и т. п. В других сценариях устройство беспроводной связи, которое описано в этом документе, может входить в состав транспортного средства и может выполнять контроль и/или передачу отчетов о рабочем состоянии транспортного средства или другие функции, ассоциированные с транспортным средством.
При использовании в данном документе "сетевое оборудование" относится к оборудованию, допускающему, сконфигурированному, выполненному с возможностью и/или действующему для осуществления прямой или косвенной связи с беспроводным устройством и/или с другим оборудованием в сети беспроводной связи, которое дает возможность и/или обеспечивает беспроводной доступ к беспроводному устройству. Примеры сетевого оборудования включают в себя, но не ограничиваются, оборудование базовой сети в базовой сети (например, оборудование, которое реализует AMF или SMF).
Отметим, что сетевое оборудование, которое описано выше, может выполнять любую обработку путем реализации любых функциональных средств или блоков. Например, в одном варианте осуществления сетевое оборудование содержит соответствующие схемы или цепи, сконфигурированные для выполнения показанных на фиг. 5 этапов. В этой связи схемы или цепи могут быть выполнены в виде схем, предназначенных для выполнения некоторой функциональной обработки, и/или одного или нескольких микропроцессоров в сочетании с запоминающим устройством. В вариантах осуществления, которые применяют запоминающее устройство, которое может быть выполнено в виде одного или нескольких типов запоминающего устройства, например постоянного запоминающего устройства (ROM), оперативного запоминающего устройства, кэш-памяти, флэш-памяти, оптических запоминающих устройств и т. д., запоминающее устройство хранит программный код, который при исполнении одним или несколькими процессорами осуществляет описанные в этом документе методики.
Фиг. 9A иллюстрирует сетевое оборудование 300 в соответствии с одним или несколькими вариантами осуществления. Как показано, сетевое оборудование 300 включает в себя схемы 310 обработки и схемы 320 связи. Схемы 320 связи конфигурируются для передачи и/или приема информации от одного или нескольких других узлов, например, посредством любой технологии связи. Схемы 310 обработки конфигурируются для выполнения описанной выше обработки, например, на фиг. 5, путем исполнения команд, сохраненных в запоминающем устройстве 330. В этой связи схемы 310 обработки могут реализовывать некоторые функциональные средства, блоки или модули.
Фиг. 9B иллюстрирует сетевое оборудование 400 в соответствии с одним или несколькими другими вариантами осуществления. Как показано, сетевое оборудование 400 реализует различные функциональные средства, блоки или модули, например, посредством схем 410 обработки на фиг. 9A и/или посредством программного кода. Эти функциональные средства, блоки или модули, например, для реализации способа на фиг. 5, включают в себя принимающий блок или модуль 410 для приема сообщения 60, которое передано или должно быть передано между разными доменами базовой сети, и для приема политики 80 защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям сообщения 60 (например, одной или нескольким частям содержимого поля 62 в сообщении 60) нужно применять или удалять обеспечение 70 безопасности между доменами. Также может включать блок или модуль 420 защиты для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой 80 защиты. В некоторых вариантах осуществления может дополнительно включаться перенаправляющий блок или модуль 430 для перенаправления сообщения 60 адресату сообщения 60 с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
Также отметим, что другое сетевое оборудование, которое описано выше, может выполнять любую обработку путем реализации любых функциональных средств или блоков. Например, в одном варианте осуществления сетевое оборудование содержит соответствующие схемы или цепи, сконфигурированные для выполнения показанных на фиг. 6 этапов. В этой связи схемы или цепи могут быть выполнены в виде схем, предназначенных для выполнения некоторой функциональной обработки, и/или одного или нескольких микропроцессоров в сочетании с запоминающим устройством. В вариантах осуществления, которые применяют запоминающее устройство, которое может быть выполнено в виде одного или нескольких типов запоминающего устройства, например постоянного запоминающего устройства (ROM), оперативного запоминающего устройства, кэш-памяти, флэш-памяти, оптических запоминающих устройств и т. д., запоминающее устройство хранит программный код, который при исполнении одним или несколькими процессорами осуществляет описанные в этом документе методики.
Фиг. 10A иллюстрирует сетевое оборудование 500 в соответствии с одним или несколькими вариантами осуществления. Как показано, сетевое оборудование 500 включает в себя схемы 510 обработки и схемы 520 связи. Схемы 520 связи конфигурируются для передачи и/или приема информации от одного или нескольких других узлов, например, посредством любой технологии связи. Схемы 510 обработки конфигурируются для выполнения описанной выше обработки, например, на фиг. 6, путем исполнения команд, сохраненных в запоминающем устройстве 530. В этой связи схемы 510 обработки могут реализовывать некоторые функциональные средства, блоки или модули.
Фиг. 10B иллюстрирует сетевое оборудование 600 в соответствии с одним или несколькими другими вариантами осуществления. Как показано, сетевое оборудование 600 реализует различные функциональные средства, блоки или модули, например, посредством схем 610 обработки на фиг. 10A и/или посредством программного кода. Эти функциональные средства, блоки или модули, например, для реализации способа на фиг. 6, включают в себя получающий блок или модуль 410 для получения политики 80 защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям сообщения 60 (например, одной или нескольким частям содержимого поля 62 в сообщении 60) нужно применять или удалять обеспечение 70 безопасности между доменами. Дополнительно может включаться передающий блок или модуль 420 для передачи политики 80 защиты.
Специалисты в данной области техники также примут во внимание, что варианты осуществления в этом документе дополнительно включают в себя соответствующие компьютерные программы.
Компьютерная программа содержит команды, которые при исполнении по меньшей мере на одном процессоре в сетевом оборудовании побуждают сетевое оборудование осуществлять любую из описанной выше соответствующей обработки. В этой связи компьютерная программа может содержать один или несколько модулей кода, соответствующих описанным выше средствам или блокам.
Варианты осуществления дополнительно включают в себя носитель, содержащий такую компьютерную программу. Этот носитель может быть выполнен в виде одного из электронного сигнала, оптического сигнала, радиосигнала или машиночитаемого носителя информации.
В этой связи варианты осуществления в этом документе также включают в себя постоянный машиночитаемый (запоминающий или записывающий) носитель с сохраненными на нем командами, которые при исполнении процессором в сетевом оборудовании побуждают сетевое оборудование работать, как описано выше.
В связи с вышеизложенным некоторые варианты осуществления будут перечислены ниже в качестве примеров.
Вариант 1 осуществления. Способ, выполняемый сетевым оборудованием, сконфигурированным в качестве посредника для одного из нескольких разных доменов базовой сети в системе беспроводной связи, содержащий: прием сообщения, которое передано или должно быть передано между разными доменами базовой сети; прием политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; применение обеспечения безопасности между доменами или удаление обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты; и перенаправление сообщения адресату сообщения с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
Вариант 2 осуществления. Способ из варианта 1 осуществления, в котором информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей.
Вариант 3 осуществления. Способ из варианта 1 осуществления, в котором информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
Вариант 4 осуществления. Способ из варианта 1 осуществления, в котором информация включает в себя один или несколько диапазонов байтов в поле и/или один или несколько диапазонов разрядов в поле, которые указывают одну или несколько частей.
Вариант 5 осуществления. Способ из варианта 1 осуществления, в котором информация включает в себя один или несколько шаблонов поиска, один или несколько маркеров и/или одну или несколько подстрок, которые указывают одну или несколько частей.
Вариант 6 осуществления. Способ из любого из вариантов 1-5 осуществления, дополнительно содержащий извлечение одной или нескольких частей содержимого поля для применения или удаления обеспечения безопасности между доменами путем синтаксического анализа содержимого с использованием информации, включенной в политику защиты.
Вариант 7 осуществления. Способ из любого из вариантов 1-6 осуществления, в котором политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей.
Вариант 8 осуществления. Способ из любого из вариантов 1-7 осуществления, в котором применяемое или удаляемое обеспечение безопасности между доменами для каждой из одной или нескольких частей содержит защиту конфиденциальности и/или защиту целостности.
Вариант 9 осуществления. Способ из любого из вариантов 1-8 осуществления, в котором сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP.
Вариант 10 осуществления. Способ из варианта 9 осуществления, в котором сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
Вариант 11 осуществления. Способ из варианта 9 осуществления, в котором поле является полем заголовка HTTP или псевдо-заголовка HTTP.
Вариант 12 осуществления. Способ из варианта 9 осуществления, в котором поле является телом или частью тела сообщения HTTP.
Вариант 13 осуществления. Способ из любого из вариантов 1-12 осуществления, дополнительно содержащий передачу услуге обнаружения запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и прием политики защиты в ответ на запрос обнаружения.
Вариант 14 осуществления. Способ из варианта 13 осуществления, содержащий передачу запроса обнаружения в ответ на прием сообщения.
Вариант 15 осуществления. Способ из любого из вариантов 13-14 осуществления, в котором услуга обнаружения реализуется функцией репозитория сети, NRF.
Вариант 16 осуществления. Способ из любого из вариантов 1-12 осуществления, содержащий прием политики защиты от сетевого оборудования по пути, который проходит сообщение от источника сообщения до адресата сообщения.
Вариант 17 осуществления. Способ из любого из вариантов 1-12 и 16 осуществления, содержащий прием политики защиты либо от источника сообщения, либо от адресата сообщения.
Вариант 18 осуществления. Способ из любого из вариантов 1-12 и 16 осуществления, содержащий прием политики защиты от другого сетевого оборудования, от которого принимается сообщение, где другое сетевое оборудование также конфигурируется в качестве посредника между разными доменами базовой сети.
Вариант 19 осуществления. Способ из любого из вариантов 1-12 и 16-18 осуществления, в котором политика защиты включается в сообщение.
Вариант 20 осуществления. Способ из любого из вариантов 1-12 и 16-19 осуществления, в котором политика защиты включается в заголовок сообщения.
Вариант 21 осуществления. Способ из любого из вариантов 1-20 осуществления, в котором сообщение является сообщением прикладного уровня, в котором поле является полем прикладного уровня, в котором содержимое поля содержит информацию прикладного уровня, и в котором обеспечение безопасности между доменами содержит защиту прикладного уровня.
Вариант 22 осуществления. Способ из любого из вариантов 1-21 осуществления, в котором сетевое оборудование конфигурируется в качестве граничного посредника обеспечения безопасности, SEPP.
Вариант 23 осуществления. Способ из любого из вариантов 1-22 осуществления, в котором домены базовой сети содержат базовые сети разных наземных сетей мобильной связи общего пользования, PLMN.
Вариант 24 осуществления. Способ, выполняемый сетевым оборудованием для упрощения защиты сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи, содержащий: получение политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; и передачу политики защиты.
Вариант 25 осуществления. Способ из варианта 24 осуществления, в котором информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей.
Вариант 26 осуществления. Способ из варианта 24 осуществления, в котором информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
Вариант 27 осуществления. Способ из варианта 24 осуществления, в котором информация включает в себя один или несколько диапазонов байтов в поле и/или один или несколько диапазонов разрядов в поле, которые указывают одну или несколько частей.
Вариант 28 осуществления. Способ из варианта 24 осуществления, в котором информация включает в себя один или несколько шаблонов поиска, один или несколько маркеров и/или одну или несколько подстрок, которые указывают одну или несколько частей.
Вариант 29 осуществления. Способ из любого из вариантов 24-28 осуществления, в котором политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей.
Вариант 30 осуществления. Способ из любого из вариантов 24-29 осуществления, в котором применяемое или удаляемое обеспечение безопасности между доменами для каждой из одной или нескольких частей содержит защиту конфиденциальности и/или защиту целостности.
Вариант 31 осуществления. Способ из любого из вариантов 24-30 осуществления, в котором сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP.
Вариант 32 осуществления. Способ из варианта 31 осуществления, в котором сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
Вариант 33 осуществления. Способ из варианта 31 осуществления, в котором поле является полем заголовка HTTP или псевдо-заголовка HTTP.
Вариант 34 осуществления. Способ из варианта 31 осуществления, в котором поле является частью тела сообщения HTTP.
Вариант 35 осуществления. Способ из любого из вариантов 24-34 осуществления, в котором передача политики защиты содержит передачу политики защиты сетевому оборудованию, сконфигурированному в качестве посредника для одного из других доменов базовой сети, для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты.
Вариант 36 осуществления. Способ из любого из вариантов 24-35 осуществления, дополнительно содержащий прием запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и передачу политики защиты в ответ на запрос обнаружения.
Вариант 37 осуществления. Способ из варианта 36 осуществления, где способ выполняется сетевым оборудованием, которое реализует функцию репозитория сети, NRF.
Вариант 38 осуществления. Способ из любого из вариантов 24-35 осуществления, где способ выполняется сетевым оборудованием по пути, который проходит сообщение от источника сообщения до адресата сообщения.
Вариант 39 осуществления. Способ из любого из вариантов 24-35 и 38 осуществления, где способ выполняется сетевым оборудованием, которое является источником сообщения либо адресатом сообщения.
Вариант 40 осуществления. Способ из любого из вариантов 24-35 и 38 осуществления, где способ выполняется сетевым оборудованием, сконфигурированным в качестве посредника между разными доменами базовой сети.
Вариант 41 осуществления. Способ из любого из вариантов 24-35 и 38-40 осуществления, в котором передача политики защиты содержит передачу сообщения с включенной в сообщение политикой защиты.
Вариант 42 осуществления. Способ из любого из вариантов 24-41 осуществления, в котором сообщение является сообщением прикладного уровня, в котором поле является полем прикладного уровня, в котором содержимое поля содержит информацию прикладного уровня, и в котором обеспечение безопасности между доменами содержит защиту прикладного уровня.
Вариант 43 осуществления. Способ из любого из вариантов 24-42 осуществления, в котором домены базовой сети содержат базовые сети разных наземных сетей мобильной связи общего пользования, PLMN.
Вариант 44 осуществления. Сетевое оборудование, сконфигурированное в качестве посредника для одного из нескольких разных доменов базовой сети в системе беспроводной связи. Сетевое оборудование конфигурируется для: приема сообщения, которое передано или должно быть передано между разными доменами базовой сети; приема политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты; и перенаправления сообщения адресату сообщения с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
Вариант 45 осуществления. Сетевое оборудование из варианта 44 осуществления, где информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей.
Вариант 46 осуществления. Сетевое оборудование из варианта 44 осуществления, где информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
Вариант 47 осуществления. Сетевое оборудование из варианта 44 осуществления, где информация включает в себя один или несколько диапазонов байтов в поле и/или один или несколько диапазонов разрядов в поле, которые указывают одну или несколько частей.
Вариант 48 осуществления. Сетевое оборудование из варианта 44 осуществления, где информация включает в себя один или несколько шаблонов поиска, один или несколько маркеров и/или одну или несколько подстрок, которые указывают одну или несколько частей.
Вариант 49 осуществления. Сетевое оборудование из любого из вариантов 44-48 осуществления, дополнительно сконфигурированное для извлечения одной или нескольких частей содержимого поля для применения или удаления обеспечения безопасности между доменами путем синтаксического анализа содержимого с использованием информации, включенной в политику защиты.
Вариант 50 осуществления. Сетевое оборудование из любого из вариантов 44-49 осуществления, где политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей.
Вариант 51 осуществления. Сетевое оборудование из любого из вариантов 44-50 осуществления, где применяемое или удаляемое обеспечение безопасности между доменами для каждой из одной или нескольких частей содержит защиту конфиденциальности и/или защиту целостности.
Вариант 52 осуществления. Сетевое оборудование из любого из вариантов 44-51 осуществления, где сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP.
Вариант 53 осуществления. Сетевое оборудование из варианта 52 осуществления, где сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
Вариант 54 осуществления. Сетевое оборудование из варианта 52 осуществления, где поле является полем заголовка HTTP или псевдо-заголовка HTTP.
Вариант 55 осуществления. Сетевое оборудование из варианта 52 осуществления, где поле является телом или частью тела сообщения HTTP.
Вариант 56 осуществления. Сетевое оборудование из любого из вариантов 44-55 осуществления, дополнительно сконфигурированное для передачи услуге обнаружения запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и приема политики защиты в ответ на запрос обнаружения.
Вариант 57 осуществления. Сетевое оборудование из варианта 56 осуществления, сконфигурированное для передачи запроса обнаружения в ответ на прием сообщения.
Вариант 58 осуществления. Сетевое оборудование из любого из вариантов 56-57 осуществления, где услуга обнаружения реализуется функцией репозитория сети, NRF.
Вариант 59 осуществления. Сетевое оборудование из любого из вариантов 44-55 осуществления, сконфигурированное для приема политики защиты от сетевого оборудования по пути, который проходит сообщение от источника сообщения до адресата сообщения.
Вариант 60 осуществления. Сетевое оборудование из любого из вариантов 44-55 и 59 осуществления, сконфигурированное для приема политики защиты либо от источника сообщения, либо от адресата сообщения.
Вариант 61 осуществления. Сетевое оборудование из любого из вариантов 44-55 и 59 осуществления, сконфигурированное для приема политики защиты от другого сетевого оборудования, от которого принимается сообщение, где другое сетевое оборудование также конфигурируется в качестве посредника между разными доменами базовой сети.
Вариант 62 осуществления. Сетевое оборудование из любого из вариантов 44-55 и 59-61 осуществления, где политика защиты включается в сообщение.
Вариант 63 осуществления. Сетевое оборудование из любого из вариантов 44-55 и 59-62 осуществления, где политика защиты включается в заголовок сообщения.
Вариант 64 осуществления. Сетевое оборудование из любого из вариантов 44-63 осуществления, где сообщение является сообщением прикладного уровня, где поле является полем прикладного уровня, где содержимое поля содержит информацию прикладного уровня, и где обеспечение безопасности между доменами содержит защиту прикладного уровня.
Вариант 65 осуществления. Сетевое оборудование из любого из вариантов 44-64 осуществления, где сетевое оборудование конфигурируется в качестве граничного посредника обеспечения безопасности, SEPP.
Вариант 66 осуществления. Сетевое оборудование из любого из вариантов 44-65 осуществления, где домены базовой сети содержат базовые сети разных наземных сетей мобильной связи общего пользования, PLMN.
Вариант 67 осуществления. Сетевое оборудование для упрощения защиты сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи. Сетевое оборудование конфигурируется для: получения политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; и передачи политики защиты.
Вариант 68 осуществления. Сетевое оборудование из варианта 67 осуществления, где информация включает в себя одно или несколько регулярных выражений, которые указывают одну или несколько частей.
Вариант 69 осуществления. Сетевое оборудование из варианта 67 осуществления, где информация включает в себя один или несколько указателей нотации объектов JavaScript, JSON, которые указывают одну или несколько частей.
Вариант 70 осуществления. Сетевое оборудование из варианта 67 осуществления, где информация включает в себя один или несколько диапазонов байтов в поле и/или один или несколько диапазонов разрядов в поле, которые указывают одну или несколько частей.
Вариант 71 осуществления. Сетевое оборудование из варианта 67 осуществления, где информация включает в себя один или несколько шаблонов поиска, один или несколько маркеров и/или одну или несколько подстрок, которые указывают одну или несколько частей.
Вариант 72 осуществления. Сетевое оборудование из любого из вариантов 67-71 осуществления, где политика защиты дополнительно указывает тип применяемого или удаляемого обеспечения безопасности между доменами для каждой из одной или нескольких частей.
Вариант 73 осуществления. Сетевое оборудование из любого из вариантов 67-72 осуществления, где применяемое или удаляемое обеспечение безопасности между доменами для каждой из одной или нескольких частей содержит защиту конфиденциальности и/или защиту целостности.
Вариант 74 осуществления. Сетевое оборудование из любого из вариантов 67-75 осуществления, где сообщение является сообщением протокола передачи гипертекста (HTTP), а поле является полем HTTP.
Вариант 75 осуществления. Сетевое оборудование из варианта 74 осуществления, где сообщение HTTP является сообщением запроса HTTP, а поле является полем пути, где содержимым поля пути является унифицированный идентификатор ресурса, URI, запроса.
Вариант 76 осуществления. Сетевое оборудование из варианта 74 осуществления, где поле является полем заголовка HTTP или псевдо-заголовка HTTP.
Вариант 77 осуществления. Сетевое оборудование из варианта 74 осуществления, где поле является частью тела сообщения HTTP.
Вариант 78 осуществления. Сетевое оборудование из любого из вариантов 67-77 осуществления, в котором передача политики защиты содержит передачу политики защиты сетевому оборудованию, сконфигурированному в качестве посредника для одного из других доменов базовой сети, для применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты.
Вариант 79 осуществления. Сетевое оборудование из любого из вариантов 67-78 осуществления, дополнительно сконфигурированное для приема запроса обнаружения, запрашивающего обнаружение политики защиты для защиты сообщения, и передачи политики защиты в ответ на запрос обнаружения.
Вариант 80 осуществления. Сетевое оборудование из варианта 79 осуществления, где способ выполняется сетевым оборудованием, которое реализует функцию репозитория сети, NRF.
Вариант 81 осуществления. Сетевое оборудование из любого из вариантов 67-78 осуществления, где способ выполняется сетевым оборудованием по пути, который проходит сообщение от источника сообщения до адресата сообщения.
Вариант 82 осуществления. Сетевое оборудование из любого из вариантов 67-78 и 81 осуществления, где способ выполняется сетевым оборудованием, которое является источником сообщения либо адресатом сообщения.
Вариант 83 осуществления. Сетевое оборудование из любого из вариантов 67-78 и 81 осуществления, где способ выполняется сетевым оборудованием, сконфигурированным в качестве посредника между разными доменами базовой сети.
Вариант 84 осуществления. Сетевое оборудование из любого из вариантов 67-78 и 81-83 осуществления, в котором передача политики защиты содержит передачу сообщения с включенной в сообщение политикой защиты.
Вариант 85 осуществления. Сетевое оборудование из любого из вариантов 67-84 осуществления, где сообщение является сообщением прикладного уровня, где поле является полем прикладного уровня, где содержимое поля содержит информацию прикладного уровня, и где обеспечение безопасности между доменами содержит защиту прикладного уровня.
Вариант 86 осуществления. Сетевое оборудование из любого из вариантов 67-85 осуществления, где домены базовой сети содержат базовые сети разных наземных сетей мобильной связи общего пользования, PLMN.
Вариант 87 осуществления. Сетевое оборудование, сконфигурированное в качестве посредника для одного из нескольких разных доменов базовой сети в системе беспроводной связи. Сетевое оборудование содержит схемы связи и схемы обработки, где сетевое оборудование конфигурируется для приема сообщения, которое передано или должно быть передано между разными доменами базовой сети; приема политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; применения обеспечения безопасности между доменами или удаления обеспечения безопасности между доменами из одной или нескольких частей в соответствии с политикой защиты; и перенаправления сообщения адресату сообщения с примененным к одной или нескольким частям или удаленным обеспечением безопасности между доменами.
Вариант 88 осуществления. Сетевое оборудование из варианта 87 осуществления, сконфигурированное для выполнения способа из любого из вариантов 2-23 осуществления.
Вариант 89 осуществления. Сетевое оборудование для упрощения защиты сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи. Сетевое оборудование содержит схемы связи и схемы обработки, где сетевое оборудование конфигурируется для получения политики защиты, которая включает в себя информацию, указывающую, к какой одной или нескольким частям содержимого поля в сообщении нужно применять или удалять обеспечение безопасности между доменами; и передачи политики защиты.
Вариант 90 осуществления. Сетевое оборудование из варианта 89 осуществления, сконфигурированное для выполнения способа из любого из вариантов 25-43 осуществления.
Вариант 91 осуществления. Компьютерная программа, содержащая команды, которые при исполнении по меньшей мере одним процессором в сетевом оборудовании побуждают сетевое оборудование выполнять способ из любого из вариантов 1-43 осуществления.
Вариант 92 осуществления. Носитель, содержащий компьютерную программу из варианта 91 осуществления, где носитель является одним из электронного сигнала, оптического сигнала, радиосигнала или машиночитаемого носителя информации.
| название | год | авторы | номер документа |
|---|---|---|---|
| ВЫБОР ЭКЗЕМПЛЯРА СЕТЕВОЙ ФУНКЦИИ | 2019 |
|
RU2748160C1 |
| СПОСОБ И ОБОРУДОВАНИЕ ДЛЯ ОБНАРУЖЕНИЯ УСЛУГ НА ОСНОВЕ СЕТЕВЫХ ФУНКЦИЙ | 2018 |
|
RU2746469C1 |
| РЕГИСТРАЦИЯ УСЛУГ В СЕТИ СВЯЗИ | 2018 |
|
RU2742289C1 |
| СПОСОБ ОБНАРУЖЕНИЯ УСЛУГ, ПРЕДОСТАВЛЯЕМЫХ ПОСРЕДСТВОМ ФУНКЦИИ СЕТЕВОГО РЕПОЗИТОРИЯ | 2018 |
|
RU2738088C1 |
| СИСТЕМЫ И СПОСОБЫ ДЛЯ УПРАВЛЕНИЯ СЕАНСОМ БЛОКА ДАННЫХ ПРОТОКОЛА (PDU), АДАПТИРОВАННОГО К ПРИЛОЖЕНИЮ | 2018 |
|
RU2758457C2 |
| ОБСЛУЖИВАЮЩАЯ ФУНКЦИЯ СЕТЕВОГО СЕГМЕНТИРОВАНИЯ | 2018 |
|
RU2737478C1 |
| РЕГИСТРАЦИЯ И ОБНАРУЖЕНИЕ УСЛУГИ В СЕТИ СВЯЗИ | 2018 |
|
RU2739495C1 |
| СПОСОБ ИСПОЛНЕНИЯ УСЛУГИ ДЛЯ ПОТРЕБИТЕЛЯ УСЛУГИ, А ТАКЖЕ СООТВЕТСТВУЮЩИЙ СЕТЕВОЙ УЗЕЛ И КОМПЬЮТЕРНЫЙ ПРОГРАММНЫЙ ПРОДУКТ | 2017 |
|
RU2740637C1 |
| ВТОРИЧНАЯ АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЬСКОГО УСТРОЙСТВА | 2017 |
|
RU2755258C2 |
| АРХИТЕКТУРА И ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ МЕЖМАШИННОГО ШЛЮЗА | 2011 |
|
RU2589860C2 |
Изобретение относится к вычислительной технике. Технический результат заключается в обеспечении безопасности между доменами для сообщения, передаваемого между разными доменами базовой сети в системе беспроводной связи. Предлагается способ защиты сообщения, выполняемый сетевым оборудованием в одном из нескольких разных доменов базовой сети в системе беспроводной связи, в котором принимают сообщение, которое передано или должно быть передано между разными доменами базовой сети; применяют обеспечение безопасности между доменами к или удаляют обеспечение безопасности между доменами из одной или более частей содержимого поля в этом сообщении в соответствии с политикой защиты, которая включает в себя информацию, указывающую, в отношении каких одной или более частей содержимого нужно применять или удалять обеспечение безопасности между доменами, причем данная информация включает в себя один или более указателей нотации объектов JavaScript (JSON), которые указывают упомянутые одну или более частей; и перенаправляют адресату сообщения данное сообщение с примененным или удаленным в отношении упомянутых одной или более частей обеспечением безопасности между доменами. 3 н. и 18 з.п. ф-лы, 13 ил.
1. Способ защиты сообщения, выполняемый сетевым оборудованием (300, 400) в одном из нескольких разных доменов базовой сети в системе (10) беспроводной связи, при этом способ содержит этапы, на которых:
принимают (110) сообщение (60), которое передано или должно быть передано между разными доменами базовой сети;
применяют (130) обеспечение безопасности между доменами к или удаляют обеспечение безопасности между доменами из одной или более частей содержимого поля в этом сообщении (60) в соответствии с политикой (80) защиты, которая включает в себя информацию, указывающую, в отношении каких одной или более частей содержимого нужно применять или удалять обеспечение безопасности между доменами, причем данная информация включает в себя один или более указателей нотации объектов JavaScript (JSON), которые указывают упомянутые одну или более частей; и
перенаправляют (140) адресату сообщения (60) данное сообщение (60) с примененным или удаленным в отношении упомянутых одной или более частей обеспечением безопасности между доменами.
2. Способ по п.1, в котором упомянутое сообщение (60) является сообщением протокола передачи гипертекста (HTTP), а упомянутое поле является полем HTTP.
3. Способ по п.2, в котором упомянутое сообщение (60) HTTP является сообщением запроса HTTP, а упомянутое поле является полем пути, при этом содержимым поля пути является унифицированный идентификатор ресурса (URI) запроса.
4. Способ по п.1, в котором упомянутая информация включает в себя одно или более регулярных выражений, которые указывают упомянутые одну или более частей.
5. Способ по п.1, в котором политика (80) защиты дополнительно указывает, для каждой из упомянутых одной или более частей, тип применяемого или удаляемого обеспечения безопасности между доменами, при этом для каждой из этих одной или более частей тип применяемого или удаляемого обеспечения безопасности между доменами содержит защиту конфиденциальности и/или защиту целостности.
6. Способ по п.1, в котором политика (80) защиты включается в упомянутое сообщение (60).
7. Способ по п.1, дополнительно содержащий этап, на котором, в ответ на упомянутый прием сообщения (60), передают в функцию репозитория сети (NRF) запрос обнаружения, запрашивающий обнаружение политики (80) защиты для защиты упомянутого сообщения (60), и принимают политику (80) защиты в ответ на запрос обнаружения.
8. Способ по п.1, дополнительно содержащий этап, на котором принимают политику (80) защиты из сетевого оборудования по пути, который проходит упомянутое сообщение (60) от источника сообщения (60) до адресата сообщения (60).
9. Способ по п.1, при этом способ выполняется граничным посредником обеспечения безопасности (SEPP).
10. Способ по п.9, в котором SEPP содержит SEPP в гостевой сети (vSEPP) и SEPP в домашней сети (hSEPP).
11. Сетевое оборудование (300, 400) для защиты сообщения, сконфигурированное для использования в одном из нескольких разных доменов базовой сети в системе (10) беспроводной связи, причем сетевое оборудование (300, 400) содержит:
схемы (320) связи; и
схемы (310) обработки, выполненные с возможностью:
принимать через схемы (320) связи сообщение (60), которое передано или должно быть передано между разными доменами базовой сети;
применять обеспечение безопасности между доменами к или удалять обеспечение безопасности между доменами из одной или более частей содержимого поля в этом сообщении (60) в соответствии с политикой (80) защиты, которая включает в себя информацию, указывающую, в отношении каких одной или более частей содержимого нужно применять или удалять обеспечение безопасности между доменами, причем данная информация включает в себя один или более указателей нотации объектов JavaScript (JSON), которые указывают упомянутые одну или более частей; и
перенаправлять через схемы (320) связи адресату сообщения (60) данное сообщение (60) с примененным или удаленным в отношении упомянутых одной или более частей обеспечением безопасности между доменами.
12. Сетевое оборудование по п.11, при этом упомянутое сообщение (60) является сообщением протокола передачи гипертекста (HTTP), а упомянутое поле является полем HTTP.
13. Сетевое оборудование по п.12, при этом упомянутое сообщение (60) HTTP является сообщением запроса HTTP, а упомянутое поле является полем пути, причем содержимым поля пути является унифицированный идентификатор ресурса (URI) запроса.
14. Сетевое оборудование по п.11, при этом упомянутая информация включает в себя одно или более регулярных выражений, которые указывают упомянутые одну или более частей.
15. Сетевое оборудование по п.11, при этом политика (80) защиты дополнительно указывает, для каждой из упомянутых одной или более частей, тип применяемого или удаляемого обеспечения безопасности между доменами, причем для каждой из этих одной или более частей тип применяемого или удаляемого обеспечения безопасности между доменами содержит защиту конфиденциальности и/или защиту целостности.
16. Сетевое оборудование по п.11, при этом политика (80) защиты включается в упомянутое сообщение (60).
17. Сетевое оборудование по п.11, в котором схемы (310) обработки дополнительно выполнены с возможностью, в ответ на упомянутый прием сообщения (60), передавать в функцию репозитория сети (NRF) запрос обнаружения, который запрашивает обнаружение политики (80) защиты для защиты упомянутого сообщения (60), и принимать политику (80) защиты в ответ на запрос обнаружения.
18. Сетевое оборудование по п.11, в котором схемы (310) обработки дополнительно выполнены с возможностью принимать политику (80) защиты из сетевого оборудования по пути, который проходит упомянутое сообщение (60) от источника сообщения (60) до адресата сообщения (60).
19. Сетевое оборудование по п.11, при этом сетевое оборудование является граничным посредником обеспечения безопасности (SEPEP).
20. Сетевое оборудование по п.19, при этом SEPP содержит SEPP в гостевой сети (vSEPP) и SEPP в домашней сети (hSEPP).
21. Машиночитаемый носитель информации, на котором сохранены машиноисполняемые команды, которые при их исполнении по меньшей мере одним процессором сетевого оборудования (300, 400) предписывают сетевому оборудованию (300, 400) выполнять способ по любому одному из пп.1-10.
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
| Печь для сжигания твердых и жидких нечистот | 1920 |
|
SU17A1 |
| US 20160021064 A1, 21.01.2016 | |||
| US 20060106802 A1, 18.05.2006 | |||
| US | |||
