51学通信

深度解析 3GPP TS 33.518：4.2.2 NRF功能安全要求（Part 1）- 切片授权的“守门人”

23分钟阅读

深度解析 3GPP TS 33.518：4.2.2 NRF功能安全要求（Part 1）- 切片授权的“守门人”

本文技术原理深度参考了3GPP TS 33.518 V18.0.0 (2023-06) Release 18规范中，关于“4.2.2 Security functional requirements on the NRF deriving from 3GPP specifications and related test cases”的核心章节，重点剖析第一个具体的安全测试用例：NF discovery authorization for specific slice，旨在为读者揭示NRF如何成为保障5G网络切片安全隔离的第一道防线。

引言：从战略地图到第一场实战演练

在上一次的技术例会中，华讯通信的5G安全架构师李慧带领团队看懂了NRF安全要求的“战略地图”。大家明白了这些要求分为“协议功能安全”和“通用安全基线”两大类。今天，团队将迎来第一次真正的“实战演练”——他们将深入“协议功能安全”的阵地，执行第一个、也是最关键的一个安全测试用例。

会议室里，气氛既兴奋又专注。李慧指着规范的4.2.2章节说：“各位，从这里开始，我们正式进入实战区。这一章所有的内容，都是为了检验NRF作为5G核心网一员，其‘专业技能’是否符合安全规范。在开始第一个具体测试之前，我们先要理解4.2.2.1节为我们设定的‘交战规则’。”

1. 交战规则：测试前的两大核心假设 (解读4.2.2.1 General approach)

李慧强调，4.2.2.1节本身不是一个测试用例，但它为后续所有测试用例的执行，设定了两个至关重要的前提假设。

In addition to the requirements and test cases in TS 33.117, clause 4.2.2, a NRF shall satisfy the following:

It is assumed for the purpose of the present SCAS that a NRF conforms to all mandatory security-related provisions pertaining to a NRF in:

  • 3GPP TS 33.501: “Security architecture procedures for 5G system”;
  • other 3GPP specifications that make reference to TS 33.501 or are referred to from TS 33.501.

1.1 假设一：通用安全基线已达标

“规范的第一句话，In addition to the requirements and test cases in TS 33.117...，这是一个强有力的声明。”李慧解释道，“它的意思是，在我们开始测试4.2.2章节里的这些高级协议安全功能之前，我们必须假设被测的NRF产品，已经满足了TS 33.117里定义的所有通用安全基线要求。”

她打了个比方：“这就像我们要考核一位特种兵的渗透和侦察技能。在考核前，我们必须假设他已经通过了基础的体能和射击测试。我们不会在考核渗透技巧时，再去检查他的枪法准不准。同样，我们在测试NRF的切片授权逻辑时，我们假设它的操作系统是加固过的，传输通道是加密的。这两部分测试是正交的、解耦的。”

1.2 假设二：核心安全架构已遵从

“第二点，规范假设NRF已经符合了TS 33.501（5G安全架构‘宪法’）以及所有引用该规范的其他标准中，与NRF相关的强制性安全条款。”

李慧进一步阐述：“这一点更为关键。它意味着，我们不是在测试NRF是否‘发明’了一套安全机制，而是在测试它是否正确并完整地实现了3GPP已经为它设计好的那套安全机制。我们的测试用例，就是将TS 33.501中的那些原则性的描述，变成了具体的、可衡量的验证步骤。”

年轻工程师小王问道：“李姐，我有点明白了。所以4.2.2.1节的作用，就是帮我们聚焦？让我们把测试的精力，完全集中在验证NRF的高级、协议层面的安全功能上，而不用在每个测试用例里都去重复检查那些基础的平台安全问题？”

“完全正确！”李慧赞许地说，“这就是规范制定者的智慧。它让我们的测试更有层次、更高效。好了，‘交战规则’明确，让我们进入第一个战壕，执行第一个测试用！”

2. 守门人职责：NF发现与切片授权 (解读4.2.2.2 & 4.2.2.2.1)

李慧在白板上写下了今天演练的核心课题：“NF discovery authorization for specific slice - 针对特定切片的NF发现授权”。

“这是NRF最核心的安全职责之一，也是保障5G网络切片商业模式的基石。”李慧开始设定今天的演练场景。

“想象一下，我们华讯通信现在有两个大客户。一个叫‘智行汽车’，他们购买了我们一个超高可靠、超低时延的uRLLC网络切片（我们称之为切片A），专门用于他们的自动驾驶车队管理。另一个客户是‘云端影音’，他们使用我们一个普通的eMBB切片（切片B），为公众提供高清视频流服务。”

“现在，安全问题来了。”李慧的表情严肃起来，“‘智行汽车’在切片A里部署了一个非常关键的应用功能，叫V2X-AF。如果这个V2X-AF，或者切片A里的任何其他NF，能够通过NRF发现并访问到‘云端影音’切片B里的NF，会发生什么？轻则造成业务干扰，重则可能成为攻击者跨越切片进行攻击的跳板，彻底摧毁网络切片的‘安全隔离’承诺。我们今天的测试，就是要验证NRF能否扮演好这个‘守门人’的角色，杜绝这种情况的发生。”

2.1 需求解读：规范的明文规定

李慧让团队成员翻到规范第7页，一起阅读这项要求的具体描述。

Requirement Name: NF discovery authorization for specific slice

Requirement Reference: TS 33.501, clause 5.9.2.1, TS 23.502, clause 4.17.4, and TS 29.510, clause 6.2.3.2.3.1.

Requirement Description: NRF is expected to be able to ensure that NF Discovery and registration requests are authorized as specified in TS 33.501, clause 5.9.2.1.

The NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instances are deployed in certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice as specified in TS 23.502, clause 4.17.4.

If included, the requester-snssai IE is expected to contain the list of S-NSSAI of the requester NF. The NRF is expected to use this to return only those NF profiles of NF instances allowing to be discovered from the slice(s) identified by this IE, according to the “allowedNssais” list in the NF Profile and NF Service as specified in TS 29.510, clause 6.2.3.2.3.1.

“这段话很长，我们来把它‘翻译’成大白话。”李慧拿起笔，在白板上拆解道：

  • 核心任务： NRF在收到一个“NF发现请求”时，必须进行授权。

  • 授权依据： 授权的核心依据是“网络切片信息”。NRF要检查，请求方NF（消费者）和被请求方NF（生产者），它们是否处在允许相互发现的切片配置中。

  • 关键参数： 请求消息中可能包含一个叫requester-snssai的参数，它表明了请求方NF属于哪个切片。同时，每个NF在向NRF注册时，其NF Profile里都有一个allowedNssais列表，声明了它允许被哪些切片的NF所发现。

  • “守门人”逻辑： NRF的判决逻辑很简单——请求方requester-snssai所代表的切片，必须是被请求方NF Profile中allowedNssais列表所允许的。 否则，一律拒绝。

“所以，我们的测试就是要验证NRF是否严格执行了这条逻辑。”

2.2 测试用例详解：一场精心设计的“越界”尝试

李慧接着带领团队，逐行剖析规范为这个需求设计的测试用例。

Test Case:

Test Name: TC_DISC_AUTHORIZATION_SLICE_NRF

Purpose: Verify that the NRF under test does not authorize slice specific discovery request for the NF instance which is not part of the requested slice, according to the slice specific discovery configuration of the requested NF instance.

“测试目的很明确：验证NRF不会批准一个‘越界’的、针对特定切片的发现请求。”

2.2.1 准备阶段 (Pre-Conditions)

Procedure and execution steps:

Pre-Conditions:

  • Test environment with the NF1 and NF2, which may be simulated.
  • The NF2 is configured with a list of S-NSSAI, which contains slice A but not slice B.
  • The NF1 is configured as a NF instance belonging to slice B and is connected in emulated/real network environment.
  • The NF1 and NF2 is successfully authenticated with the NRF under test.

李慧开始分配任务：“好了，现在我们来搭建我们的‘演练场’。”

“小王，你负责模拟NF2。根据我们的场景，NF2就是‘智行汽车’的V2X-AF。按照预设条件，你在它的配置里明确声明，它只属于切片A (uRLLC)，不属于切片B (eMBB)。”

“张工，你负责模拟NF1。NF1在这里扮演‘云端影音’切片里的一个业务功能，比如内容分发服务器。你在它的配置里，让它属于切片B。注意，为了让测试场景更真实，你可以让NF1的allowedNssais列表里也只包含切片B，表示它只愿意被切片B的同伴发现。”

“最后，确保我们的测试环境里，NF1和NF2都能与被测的NRF正常通信，并且已经通过了基础的身份认证。我们不测试认证，我们只测认证之后的授权。”

2.2.2 执行阶段 (Execution Steps)

Execution Steps:

  1. The NF2 registers at the NRF under test with a list of S-NSSAI.
  1. The NF1 sends an Nnrf_NFDiscovery_Request to the NRF under test with the expected service name of NF2, NF type of the expected NF2.
  1. The NRF under test determines that NF2 instance only allows discovery from NFs belonging to slice A, according to the “allowedNssais” list stored in NF2 Profile.

李慧对着执行步骤，下达了清晰的指令：

“第一步：小王，启动你的NF2，让它向NRF发起注册请求。在请求中，明确带上它的切片身份——它属于切片A。”

（注：原文此处步骤2和3的描述似乎与测试目的有些逻辑上的偏差，更合理的测试流程应该是让属于切片A的NF2去发现属于切片B的NF1。我们将基于测试目的和行业普遍理解，将流程调整为更符合逻辑的步骤进行解读）

“第二步，也是最关键的一步：小王，操作你的NF2，向NRF发起一个**Nnrf_NFDiscovery_Request（NF发现请求）**。在请求里，你明确提出：‘我想找一个能够提供视频流服务（NF1的服务类型）的NF，并且我要求这个NF必须是属于切片B的。’”

李慧解释道：“这是一个非常巧妙的‘攻击’。NF2明明自己只在切片A，却‘谎称’自己需要切片B的服务，试图‘钓鱼’，让NRF把切片B的NF1信息泄露给它。”

“第三步，轮到NRF表演了。当NRF收到这个请求后，它内部的判决逻辑必须被触发。它会查看请求方NF2的Profile，发现NF2只被授权在切片A活动。然后它看到请求的目标是切片B的资源。此时，一个合格的NRF必须做出判断：这是一个越权请求！”

2.2.3 预期结果 (Expected Results)

Expected Results:

The NRF under test returns a response with “403 Forbidden” status code, as specified in clause 5.3.2.2.2 of TS 29.510.

“最后，我们来验收‘战果’。”李慧说，“如果NRF的‘守门人’职责履行到位，我们会在小王的测试终端上看到什么？不是NF1的详细信息，也不是一个空列表，而是一个明确的、表示‘禁止访问’的HTTP状态码——‘403 Forbidden’！”

她强调：“为什么是403而不是其他？因为这是一种清晰的安全响应。它告诉请求方：‘我知道你要找的东西可能存在，但你没有权限去发现它。’ 这与‘404 Not Found’（找不到）有本质区别，后者可能会让攻击者继续尝试其他参数。而403，则是干脆利落地关上了大门。”

2.2.4 证据格式 (Expected format of evidence)

Expected format of evidence:

Evidence suitable for the interface, e.g., evidence can be presented in the form of screenshot/screen-capture.

“测试还没完。”李慧补充道，“我们必须留下证据。将整个请求和响应过程，包括最终显示的‘403 Forbidden’错误，进行截图或抓包。这份证据将写入我们的测试报告，作为该NRF产品此项功能是否合格的最终判据。”

4. 总结

今天的实战演练结束了。通过一个具体的、精心设计的测试用例，李慧的团队不仅学会了如何操作，更深刻地理解了NRF在5G切片安全中扮演的无可替代的角色。

TS 33.518中的TC_DISC_AUTHORIZATION_SLICE_NRF测试用例，它不是一个简单的功能测试，而是一个深刻的安全拷问：

  • 拷问NRF：你是否真正理解并严格执行了5G的安全隔离原则？

  • 拷问网络：我们赖以信赖的切片隔离，其最基础的一环是否足够坚固？

对于运营商和设备商而言，确保NRF能够完美通过此项测试，是构建可信、安全、可商用的5G网络切片服务的第一步，也是最关键的一步。这个小小的“403 Forbidden”状态码，背后承载的，是整个5G to B商业蓝图的安全基石。

FAQ

Q1：为什么在这个测试中，预期的正确结果是返回“403 Forbidden”，而不是一个空列表？

A1：这是一个非常重要的安全设计原则，体现了“最小信息泄露”原理。如果NRF返回一个空列表，攻击者可能会解读为“切片B中当前没有满足条件的NF实例”，但这并没有明确拒绝他的越权行为，他可能会继续尝试发现其他类型的服务。而返回“403 Forbidden”，则是一个明确的授权失败信号，它告诉请求方：“你的请求本身就是非法的，因为你没有权限查询该切片的信息”，这能更有效地阻止进一步的探测性攻击。

Q2：在NF的Profile中，allowedNssais这个参数具体是如何工作的？

A2：allowedNssais（允许的单网络切片选择辅助信息列表）是NF生产者Profile中的一个关键安全属性。当一个NF（比如NF1）向NRF注册时，它可以包含这个列表，声明“我只允许来自这些切片的NF发现我”。例如，NF1的allowedNssais列表里只有切片B，那么当来自切片A的NF2发起发现请求时，即使请求本身格式完全正确，NRF在匹配时也会因为NF2的切片身份（切片A）不在NF1的允许列表（切片B）中，而拒绝这次发现。

Q3：如果一个NF（比如一个共享的UDM）同时服务于多个切片，这个测试会如何变化？

A3：很好的问题，这是更复杂的场景。假设NF1（UDM）同时服务于切片A和切片B，那么在它注册时，它的NF Profile中的allowedNssais就会包含切片A和切片B。在这种情况下，当只属于切片A的NF2来请求发现一个服务于切片A的NF1时，NRF会授权该请求并返回NF1的信息。但如果NF2请求发现一个服务于切片B的NF1，即使是同一个NF1实例，NRF依然会根据请求的目标切片（切片B）与请求方身份（切片A）不匹配的原则，结合策略，大概率会拒绝该请求，以维持切片间的逻辑隔离。测试用例会变得更复杂，需要验证多种合规和违规的组合。

Q4：这个测试用例和OAuth2.0在5G中的应用有什么关系？

A4：它们是5G服务化接口安全机制的两个不同但相互关联的层面。本测试用例关注的是NRF在服务发现阶段基于切片的访问控制，这是第一道防线。而OAuth2.0框架则用于更通用的服务访问授权。一个典型的流程是：NF消费者（如AMF）首先通过NRF发现它需要的NF生产者（如SMF），这个过程受本测试用例的规则约束。发现成功后，AMF会向NRF（或独立的AUSF/SEPP）请求一个Access Token，然后携带这个Token去访问SMF的服务。SMF会验证Token的有效性来决定是否提供服务。可以说，切片发现授权是更 spezifisch 的、前置的授权检查。

Q5：如果一个NRF产品没有通过这项测试，会有什么严重的现实后果？

A5：后果非常严重。这意味着5G网络切片最核心的安全承诺——“隔离性”——被打破了。具体来说：1）租户数据泄露：一个企业客户（如‘智行汽车’）的NF可能发现并尝试攻击另一个企业客户（如某金融公司）的NF，窃取敏感数据。2）服务中断：恶意的或配置错误的NF可能会发现并向不相关的切片中的关键NF（如PCF, Policy Control Function）发送大量垃圾请求，导致该切片策略失控，业务瘫痪。3）商业模式崩溃：运营商无法向客户保证其购买的切片资源是安全隔离和专享的，这将严重打击5G在垂直行业（to B）应用的信誉和可行性。

关系图谱