WO2020001300A1 - Procédé et solution permettant d'éviter des problèmes avec un routage inter-plmn et tls dans une architecture basée sur un service 5g - Google Patents

Procédé et solution permettant d'éviter des problèmes avec un routage inter-plmn et tls dans une architecture basée sur un service 5g Download PDF

Info

Publication number
WO2020001300A1
WO2020001300A1 PCT/CN2019/091449 CN2019091449W WO2020001300A1 WO 2020001300 A1 WO2020001300 A1 WO 2020001300A1 CN 2019091449 W CN2019091449 W CN 2019091449W WO 2020001300 A1 WO2020001300 A1 WO 2020001300A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
rendezvous point
hsepp
vsepp
vnrf
Prior art date
Application number
PCT/CN2019/091449
Other languages
English (en)
Inventor
Sridhar Bhaskaran
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN201980017951.0A priority Critical patent/CN111819874B/zh
Publication of WO2020001300A1 publication Critical patent/WO2020001300A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies

Definitions

  • Embodiments of the present disclosure relate to the field of communication technologies.
  • a user equipment device or terminal device For mobility network, a user equipment device or terminal device (collectively referred to as UE hereinafter) has mobility requirements.
  • the UE may trigger a resume procedure
  • the UE may trigger a procedure from an INACTIVE to CONNECTED state.
  • the UE may move from a source base station (the base station can be an eNB or a gNB) to a target base station (eNB/gNB) when triggering these procedures.
  • the source eNB/gNB will have to send the UE’s context to the target eNB/gNB.
  • the UE's context includes old cipher and integrity protection algorithms used between the UE and the source eNB/gNB.
  • This invention applies to 5G packet core networks when a security and edge protection proxy (SEPP) is used at the edge of a public land mobile network (PLMN) for the security protection of messages exchanged with other public land mobile networks (PLMNs) .
  • SEPP security and edge protection proxy
  • HTTP/2 messages are routed based on the ": authority" pseudo header as specified in IETF RFC 7540 and the HTTP routing mechanism specified in IETF RFC 7230.
  • the SEPP in PLMN A and PLMN B cant intercept the messages as the messages will be end to end encrypted between NFa and NFb.
  • the SEPP In order to provide security and edge protection of the messages as per the policies of each PLMN, the SEPP has to intercept the messages. In order to intercept the messages, the TLS connection has to be terminated and reinitiated on the other side by the SEPP, acting like a Man-in-the-middle proxy.
  • Embodiments of the present disclosure provide a method to avoid this issue by setting up a hop by hop TLS via the SEPP and at the same time not changing the routing behavior of HTTP.
  • the main idea is to expose "rendezvous points" in SEPP for each service of remote PLMNs with which the SEPP has a inter operator relationship.
  • the "rendezvous points" in SEPP are established by configuration.
  • VNRF The NRF in the VPLMN (VNRF) replaces the discovered NF service's FQDN (fully qualified domain name) with the FQDN of the "rendezvous point" exposed by the VSEPP for the NF service and for that specific HPLMN.
  • VNRF replaces the ⁇ apiRoot ⁇ of the discovered NF service with the “rendezvous point” information for the NF service of the particular HPLMN.
  • FIG. 1 is a schematic chart of an end to end TLS
  • FIG. 2 is a schematic chart of a hop by hop TLS
  • FIG. 3 is a schematic flowchart of a Rendezvous Point Exposure Based Solution for SEPP as Service Relay
  • FIG. 4 is a schematic chart of a configuration table at NRF
  • FIG. 5 is a schematic chart of a configuration table at SEPP
  • FIG. 6 is a schematic chart of a configuration table at SEPP
  • FIG. 7 is a schematic flowchart of a Rendezvous Point Exposure Based Solution for SEPP as Service Relay
  • FIG. 8 is a simplified block diagram of components of 3GPP 5G Core Network Products implemented as NF Service.
  • FIG. 9 is a simplified block diagram of components of 3GPP 5G Core Network Products implemented as NF Service.
  • FIG. 10 is a simplified block diagram of components of 3GPP 5G Core Network Products implemented as NF Service.
  • the invention tries to avoid this issue by setting up a hop by hop TLS via the SEPP and at the same time not changing the routing behavior of HTTP.
  • the key aspect of this solution is to achieve everything by configuration and inter PLMN agreements without impacting any fundamentals of HTTP routing, stage 2 architectural requirements and CT4 API design. It should be noted that the messages are routed hop by hop and TLS is terminated hop by hop. There will not be any issues with certificates as each entity uses the certificate of its own and there is no faking involved here.
  • the vNRF is configured as follows:
  • hNRF FQDN for the PLMN ID of HPLMN Rendezvous point exposed by VSEPP for the NF discovery service of the NRF in HPLMN
  • the vNRF thinks that the "rendezvous point" exposed by VSEPP itself is the HNRF FQDN. It doesnt know that it is the VSEPP that is acting as the meeting point for the HNRF. Hence the vNRF sets the ": authority" pseudo header in the HTTP/2 message as the "rendezvous point" address.
  • VSEPP When the VSEPP receives the request at the "rendezvous point" FQDN and URI path, the VSEPP by configuration knows which is the mapping next hop in the relay.
  • the VSEPP is configured as follows:
  • the VSEPP sends the HTTP/2 message with ": authority” pseudo header set to "rendezvous point exposed by HSEPP for the HNRF” and the ": path” pseudo header set to the "rendezvous point” URI path exposed by the HSEPP for the NF discovery service of the HNRF. This is shown in figure 5.
  • An alternative way of storing the above configuration is shown in figure 6.
  • the HSEPP When the HSEPP receives the request at the "rendezvous point" , it knows by configuration to which NF service producer in the HPLMN it needs to relay the message. Hence it relays the message to HNRF.
  • HNRF responds by providing the FQDN of the NF service producer in the NF discovery response.
  • the VNRF replaces the NF service producer FQDN in the discovery response with the "Rendezvous point exposed by VSEPP for the NF service discovered in the HPLMN" and replaces the NF service producer's the API URI in the discovery response with the "Rendezvous point” 's URI exposed by VSEPP for the NF service discovered in the HPLMN.
  • the NF service consumer receives this response, it thinks that this "rendezvous point" FQDN is in fact the actual NF service producer FQDN.
  • the structure of the NFService Profile returned in the NF discovery response is specified in clause 6.2.6.2.4 of 3GPP TS 29.510. It is shown below for reference.
  • the "fqdn” and “apiPrefix” part of the NF Service profile which are replaced by the VNRF with the FQDN and API URI of the "rendezvous point" are highlighted.
  • NF service consumer sends a service request to the NF service producer with ": authority” part of the HTTP/2 message set to "rendezvous point” returned in step 6 and the ": path” part of the HTTP/2 message set to the "rendezvous point” URI path returned in step 6..
  • VSEPP receives the request at the rendezvous point and maps it to HSEPP rendezvous point by configuration.
  • HSEPP receives the request at the rendezvous point for the NF service producer and based on configuration the HSEPP knows to which NF service producer it needs to relay the request.
  • HSEPP looks similar to figure 3 and 4 with the exception that instead of HSEPP URI /FQDN on the rightmost column it is the actual NF service producer's FQDN /URI.
  • IPX The role of IPX between the SEPPs on whether they also act as "Relays" exposing rendezvous point or they acts bump in TLS is upto IPX deployment.
  • SEPP is a "Service Relay" .
  • the figure 7 explains the solution.
  • the key aspect of this solution is to achieve everything by configuration and inter PLMN agreements without impacting any fundamentals of HTTP routing, stage 2 architectural requirements and CT4 API design. It should be noted that the messages are routed hop by hop and TLS is terminated hop by hop. There will not be any issues with certificates as each entity uses the certificate of its own and there is no faking involved here.
  • NF service consumer in VPLMN wants to communicate with an NF service producer in HPLMN, first the NF service discovery happens.
  • the NF service discovery request itself needs to go through vSEPP and hSEPP when the vNRF routes the request to hNRF.
  • the NF service consumer in VPLMN sets the "authority" pseudo header in the HTTP/2 message as the FQDN of the vNRF host which it acquires either by configuration or from NSSF during slice selection.
  • the vNRF is configured as follows:
  • hNRF FQDN for the PLMN ID of HPLMN Rendezvous point exposed by VSEPP for the NRF in HPLMN.
  • the vNRF thinks that the "rendezvous point" exposed by VSEPP itself is the HNRF FQDN. It doesnt know that it is the VSEPP that is acting as the meeting point for the HNRF. Hence the vNRF sets the "authority" pseudo header in the HTTP/2 message as the "rendezvous point" address.
  • the VSEPP When the VSEPP receives the request at the "rendezvous point" , the VSEPP by configuration knows which is the mapping next hop in the relay.
  • the VSEPP sends the HTTP/2 message with "authority" pseudo header set to "rendezvous point exposed by HSEPP for the HNRF" .
  • the HSEPP When the HSEPP receives the request at the "rendezvous point" , it knows by configuration to which NF service producer in the HPLMN it needs to relay the message. Hence it relays the message to HNRF.
  • HNRF responds by providing the FQDN of the NF service producer in the NF discovery response.
  • VNRF replaces the NF service producer FQDN in the discovery response with the "Rendezvous point exposed by VSEPP for the NF service discovered in the HPLMN" .
  • the NF service consumer receives this response, it thinks that this "rendezvous point" FQDN is in fact the actual NF service producer FQDN.
  • NF service consumer sends a service request to the NF service producer with "authority" part of the HTTP/2 message set to "rendezvous point" returned in step 6.
  • VSEPP receives the request at the rendezvous point and maps it to HSEPP rendezvous point by configuration.
  • HSEPP receives the request at the rendezvous point for the NF service producer and based on configuration the HSEPP knows to which NF service producer it needs to relay the request.
  • IPX The role of IPX between the SEPPs on whether they also act as "Relays" exposing rendezvous point or they acts bump in TLS is upto IPX deployment.
  • the invention is applicable to 5G SEPP and NRF products.
  • the key components of these products are shown in figure 8 to 10.
  • NF service in VPLMN wants to communicate with an NF service in HPLMN (or vice-versa) then the NF service at the application level need not be aware of the presence of SEPP. They would route the HTTP/2 messages just like how they would route towards an NF service in the same PLMN.
  • IPX-es are implemented can be left upto the IPX provider. This solution does not mandate that IPX also implement "rendezvous point" . An IPX for example could implement "Bump in TLS” solution if they want. However the solution#3 suggested by SA3 requires IPX also to understand the custom headers /payloads 3GPP defines for HTTP routing purpose.
  • mapping table in VSEPP to map the "rendezvous point" FQDN and API URI to the next hop FQDN /API URI, where the next hop could be an IPX or a HSEPP.
  • mapping table in HSEPP to map the "rendezvous point" FQDN and API URI to the NF service's FQDN /API URI.
  • mapping table in the VNRF on a per PLMN ID basis to map the FQDN and API URI of the NF services of another PLMN to a "rendezvous point" FQDN and URI in exposed by the VSEPP in the VPLMN.
  • the disclosed system, apparatus, and method may be implemented in other manners.
  • the described apparatus embodiment is merely an example.
  • the unit division is merely logical function division and may be other division in actual implementation.
  • a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed.
  • the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces.
  • the indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
  • the present disclosure may be implemented by hardware, firmware or a combination thereof.
  • the foregoing functions may be stored in a computer-readable medium or transmitted as one or more instructions or code in the computer-readable medium.
  • the computer-readable medium includes a computer storage medium and a communications medium, where the communications medium includes any medium that enables a computer program to be transmitted from one place to another.
  • the storage medium may be any available medium accessible to a computer.
  • the computer readable medium may include a random access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable read-only memory (EEPROM) , a compact disc read-only memory (CD-ROM) or other optical disk storage, a disk storage medium or other disk storage, or any other medium that can be used to carry or store expected program code in a command or data structure form and can be accessed by a computer.
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • CD-ROM compact disc read-only memory
  • any connection may be appropriately defined as a computer-readable medium.
  • the coaxial cable, optical fiber/cable, twisted pair, DSL or wireless technologies such as infrared ray, radio and microwave
  • the coaxial cable, optical fiber/cable, twisted pair, DSL or wireless technologies such as infrared ray, radio and microwave are included in fixation of a medium to which they belong.
  • a disk and disc used by the present disclosure includes a compact disc (CD) , a laser disc, an optical disc, a digital versatile disc (DVD) , a floppy disk and a Blu-ray disc, where the disk generally copies data by a magnetic means, and the disc copies data optically by a laser means.
  • CD compact disc
  • DVD digital versatile disc
  • a floppy disk a floppy disk and a Blu-ray disc
  • the disk generally copies data by a magnetic means
  • the disc copies data optically by a laser means optically by a laser means.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de négociation d'algorithme de sécurité, une station de base et un équipement d'utilisateur. Le procédé consiste à recevoir un indicateur et un identifiant d'algorithme à partir d'une station de base cible, à réserver une première clé sur la base de l'indicateur, la première clé étant dérivée pour une station de base source, et à dériver une clé de sécurité sur la base de la première clé et d'un algorithme correspondant à l'identifiant d'algorithme. Plusieurs signalisation sont réduites à l'aide des solutions proposées par la présente invention.
PCT/CN2019/091449 2018-06-29 2019-06-16 Procédé et solution permettant d'éviter des problèmes avec un routage inter-plmn et tls dans une architecture basée sur un service 5g WO2020001300A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201980017951.0A CN111819874B (zh) 2018-06-29 2019-06-16 避免基于5g服务的架构中plmn间路由和tls问题的方法和解决方案

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN201831024206 2018-06-29
IN201831024206 2018-06-29

Publications (1)

Publication Number Publication Date
WO2020001300A1 true WO2020001300A1 (fr) 2020-01-02

Family

ID=68984721

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/091449 WO2020001300A1 (fr) 2018-06-29 2019-06-16 Procédé et solution permettant d'éviter des problèmes avec un routage inter-plmn et tls dans une architecture basée sur un service 5g

Country Status (2)

Country Link
CN (1) CN111819874B (fr)
WO (1) WO2020001300A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112468483A (zh) * 2020-11-24 2021-03-09 中国电子科技集团公司第三十研究所 基于5g边缘防护代理的服务动态分配及信令防护方法
WO2021057850A1 (fr) * 2019-09-27 2021-04-01 华为技术有限公司 Procédé, appareil et système de routage de fonction de réseau
EP3937521A1 (fr) * 2020-07-09 2022-01-12 Deutsche Telekom AG Procédé pour une fonctionnalité d'échange et/ou d'interfonctionnement améliorée entre un premier réseau de communication mobile et un second réseau de communication mobile, fonction d'échange de réseau, programme et produit de programme informatique

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117354232A (zh) * 2022-06-29 2024-01-05 中兴通讯股份有限公司 消息的路由方法及装置、系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107615257A (zh) * 2015-05-20 2018-01-19 佳能株式会社 通信设备、通信方法及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017049505A1 (fr) * 2015-09-23 2017-03-30 华为技术有限公司 Procédé d'émission de données et dispositif de communications
US10292038B2 (en) * 2015-11-09 2019-05-14 Lg Electronics Inc. Method for acquiring business operator network identification number of visited network
JP6724232B2 (ja) * 2016-07-29 2020-07-15 エルジー エレクトロニクス インコーポレイティド 無線通信システムにおけるネットワークスライスベースのｎｒのためのセル特定手順を実行する方法及び装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107615257A (zh) * 2015-05-20 2018-01-19 佳能株式会社 通信设备、通信方法及存储介质

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ERICSSON: "SEPP Flow", 3GPP SA WG2 MEETING #127BIS S2-185490, 1 June 2018 (2018-06-01), XP051535981 *
ERICSSON: "TLS and Routing Solutions Update", 3GPP TSG SA WG3 (SECURITY) MEETING #91 S3-181957, 20 April 2018 (2018-04-20), XP051457201 *
HUAWEI: "Discussion on TLS and Inter PLMN Routing through SEPP", 3GPP TSG CT WG4 MEETING #85BIS C4-185052, 29 June 2018 (2018-06-29), pages 5, XP051472172 *
TIM: "Analysis of different approaches for implementing SBA security over N32 reference point", 3GPP TSG SA WG3 (SECURITY) MEETING #90 S3-180028, 26 January 2018 (2018-01-26), XP051390476 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021057850A1 (fr) * 2019-09-27 2021-04-01 华为技术有限公司 Procédé, appareil et système de routage de fonction de réseau
EP3937521A1 (fr) * 2020-07-09 2022-01-12 Deutsche Telekom AG Procédé pour une fonctionnalité d'échange et/ou d'interfonctionnement améliorée entre un premier réseau de communication mobile et un second réseau de communication mobile, fonction d'échange de réseau, programme et produit de programme informatique
CN112468483A (zh) * 2020-11-24 2021-03-09 中国电子科技集团公司第三十研究所 基于5g边缘防护代理的服务动态分配及信令防护方法
CN112468483B (zh) * 2020-11-24 2022-02-08 中国电子科技集团公司第三十研究所 基于5g边缘防护代理的服务动态分配及信令防护方法

Also Published As

Publication number Publication date
CN111819874B (zh) 2021-09-14
CN111819874A (zh) 2020-10-23

Similar Documents

Publication Publication Date Title
WO2020001300A1 (fr) Procédé et solution permettant d'éviter des problèmes avec un routage inter-plmn et tls dans une architecture basée sur un service 5g
US11825310B2 (en) Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
KR102351355B1 (ko) 네트워크 슬라이싱 서빙 기능
EP3557913B1 (fr) Procédé et appareil de mise à jour de politique de sélection de tronçon de réseau
US11832172B2 (en) Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
JP5602937B2 (ja) リレーノードと構成エンティティの間の接続性の確立
US20220240171A1 (en) Methods, systems, and computer readable media for optimized routing of messages relating to existing network function (nf) subscriptions using an intermediate forwarding nf repository function (nrf)
EP3860174A1 (fr) Chemin, procédé et dispositif de traitement d'informations de chemin, support de stockage, et dispositif électronique
US20220394453A1 (en) Methods, systems, and computer readable media for using service communications proxy (scp) or security edge protection proxy (sepp) to apply or override preferred-locality attribute during network function (nf) discovery
JP7043631B2 (ja) Ｓｓｃモードを決定するための方法および装置
US11076281B1 (en) 5G core roaming network function proxy in an IPX network
US11950178B2 (en) Methods, systems, and computer readable media for optimized routing of service based interface (SBI) request messages to remote network function (NF) repository functions using indirect communications via service communication proxy (SCP)
US20220295282A1 (en) Methods, systems, and computer readable media for delegated authorization at security edge protection proxy (sepp)
CN106576285B (zh) 一种apn配置方法、用户设备和配置服务器
US11864093B2 (en) Methods, systems, and computer readable media for communicating delegated network function (NF) discovery results between service communication proxies (SCPs) and using the delegated NF discovery results for alternate routing
US11789803B2 (en) Error handling framework for security management in a communication system
US20230171099A1 (en) Methods, systems, and computer readable media for sharing key identification and public certificate data for access token verification
CN113661696B (zh) 用于处理可伸缩fqdn的系统和方法
CN113382410A (zh) 通信方法和相关装置及计算机可读存储介质
US11765030B2 (en) Methods, systems, and computer readable media for registering application functions using common application programming interface framework
RU2783588C2 (ru) Способ конфигурации сети и устройство связи
EP4243379A1 (fr) Procédés, systèmes et supports lisibles par ordinateur pour découvrir des producteurs de service de fonction de réseau dans un réseau hiérarchique
KR20170122575A (ko) 분산된 게이트웨이간 단말의 이동성 관리 장치 및 방법
CN115942314A (zh) 一种证书管理方法和装置
CN117939454A (zh) 信息传输方法、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19825511

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19825511

Country of ref document: EP

Kind code of ref document: A1