需求分析

关联文档

  • 《1、面向垂直行业的N4接口规范（报批稿）v1.0.0》第 6.1.5.3 章节

  • 《2、面向垂直行业的边缘N4解耦UPF设备规范0128》第 6.7 章节

  • 《3、面向垂直行业的边缘N4解耦UPF测试规范v2.0》第 11.9 章节

应用场景描述

  1. UseCase 1: 单纯面向业务的头增强应用场景。对所有 UE 访问指定 URL/SNI/IP 的 HTTP/S 数据报文都进行 “用户特征信息” 增强头插入。

  2. UseCase 2: 需要同时面向用户和业务的头增强应用场景。对指定的 UE 访问指定 URL/SNI/IP 的 HTTP/S 数据报文进行 “用户特征信息” 增添头插入。

HTTP 头增强需求点

  1. UPF 支持接收 SMF 下发的头增强策略。

  2. UPF 支持根据 SMF 下发的头增强策略向指定的 “自有业务/第三方合作业务 HTTP 请求报文” 的 HTTP Header 中插入：手机号、UE ID、UE IP、RAT 等标准增强头字段。

  3. UPF 支持自定义扩展增强头字段，大小至少 4 对（包括：字段名和字段值）。

  4. 各增强头字段是否插入可进行配置。

  5. 各增强头字段取值需符合中国移动规范，插入的格式需符合 5G 的码号格式定义（e.g. msisdn-8618867101079、imsi-460000000000001、imei-247456789012371）。

  6. UPF 支持手机号（x-up-calling-line-id）插入的防欺诈功能，支持清除原有手机号信息，替换为真实的手机号。

  7. UPF 支持 HTTP 头增强防欺诈功能，包括：

    1. 分片完整性的防欺诈要求

    2. 分片检测顺序的防欺诈要求

    3. 缓存时长的防欺诈要求

    4. 分片乱序的防欺诈要求

    5. 关键字段被分割的防欺诈要求

  • 注 1：用户面 HTTP 业务类型有两种：1）自有业务；2）第三方合作业务。

  • 注 2：UPF 根据 “URL 头增强白名单” 来判别是否需要对 HTTP 业务进行头增强。

  • 注 3：HTTP 头增强白名单类型有：1）自有业务 HTTP 头增强 URL 白名单；2）第三方合作业务 HTTP 头增强 URL 白名单。

  • 注 4：HTTP 头增强扩展类型分为：

    • 基础类型：该类型的字段名由规范固定，字段值由 UPF 补充。包括：手机号（x-up-calling-line-id）、RAT（x-up-bear-type，映射关系见附录 A）、UE IP（x-forwarded-for）、UE ID（IMSI/SUPI、MSISDN/GPSI、IMEI/EPI）、APN/DNN 等字段。

    • 自定义类型：至少 4 对（包括：字段名和字段值），该类型的字段名和字段值均由用户自定义输入，UPF 仅进行填充。

  • 注 5：增强头字段支持是否插入可配置。MP2 下发预定义规则，N4 下发规则激活。

  • 注 6：字段取值需要符合中国移动规范，例如：5G 码号格式定义。

  • 注 7：HTTP Headers 有可能存在不同的分片中。

HTTPS 头增强需求点

  1. UPF 支持识别 TLS Record 协议中的 client_hello 消息。

  2. UPF 支持根据 client_hello 消息中的 SNI 域名、或数据报文的目的 IP 地址是否存在 “HTTPS 头增强白名单” 中来判别是否进行 HTTPS 头增强插入。若 client_hello 消息被分片了则不进行头增强插入。

  3. 如果 HTTPS 头增强白名单被配置为仅根据数据报文的目的 IP 地址来判别是否进行 HTTPS 头增强插入时，即使 client_hello 消息中没有携带 SNI 域名，UPF 也应该能够进行增强头插入。

  4. UPF 支持 SNI 域名防欺诈功能，对 SNI 域名及其对应的业务平台目的 IP 地址进行匹配校验，若不匹配则不插入增强头；

  5. UPF 支持在指定 extension_type 的 extension 中插入 sub extension。

  6. UPF 支持对指定的 sub extension 的内容和密钥进行加密（e.g. RC4 算法）。

  7. UPF 支持灵活配置 extension_type 的值（e.g. 17516）。

  8. UPF 支持灵活配置插入的 sub extension 字段。

  9. UPF 支持灵活配置 sub extension 是否加密、以及采用哪种加密算法。

  10. UPF 支持灵活配置对不同的业务（目的 IP 和 SNI）类型，加密不同的 sub extension 字段；

  11. UPF 应支持对 client_hello 消息进行头增强字段正确性的校验；

    1. 对于 client_hello 消息未分片的情况，如果发现源 client_hello 消息中已有 1 个或者多个序号为 17516 的 extension 字段，则使用正确的手机号和格式对全部已有的 17516 字段进行修正，或者阻断当前业务流。

    2. 对于 client_hello 消息分片的情况，检测是否有序号为 17516 的字段，如果无此字段，则正常转发；如果有此字段，则阻断当前业务流；如果无法判断各个分片是否有此字段，则阻断当前业务流。

  12. 若 HTTPS 增强头字段的采用明文的方式进行插入，则 UPF 应支持分片检测顺序，分片乱序以及关键字被分割等场景的防欺诈要求；

  13. 对于插入增强头字段后对 TCP Sequence 的影响，即插入增强头字段可能造成 content length 变化，以及包长超过 MTU 导致的新包增加和序号适配问题，UPF 在 HTTPS 头增强中也应支持此功能。

  • 注 1：若 Web Server 实施了基于 Hostname 的 HTTP Virtual Host，那么 C/S 建立 HTTPS 连接时通常需要指定 SNI 域名；反之，则不需要。

  • 注 2：所以，HTTPS 业务类型除了区分 “1）自有业务；2）第三方合作业务” 之外，还需要区分 “1）目的 IP 地址业务；2）SNI 域名业务”。

  • 注 3：HTTPS 头增强白名单中具有 “仅根据数据报文的目的 IP 地址来进行判别” 标志位。

  • 注 4：HTTPS 头增强白名单中的 SNI 域名字段还应该记录与之对应的 IP 地址，以此完成 SNI 域名防欺诈功能。