# Spec WG11: Study on Security for Near Real Time RIC and xApps, Feb, 2024 ## 現有的xApp防護機制  - **Conflict Mitigation:** 解決來自多個 xApp 的潛在重疊或衝突的請求 - **Subscription management:** 管理從 xApp 到 E2 節點的訂閱並強制執行策略授權 - **Management services:** xApp 的生命週期管理(加入、部署、資源管理和終止)以及Near-RT RIC 的 FCAPS 管理(日誌記錄、追蹤、指標收集) - **Security:** 為xApps提供安全方案。此功能的目標之一是防止惡意 xApp 濫用無線電網路資訊(例如匯出到未經授權的外部系統)和/或透過 RAN 功能控制能力 <br> > Security功能是Near-RT RIC架構中的佔位符,尚未指定。本研究中提出的要求和解決方案將支援該功能的規格。 ## 須考量的安全層面 - xApps 應透過Near-RT RIC API 與Near-RT RIC 平台進行通訊。 - xApp 應使用Near-RT RIC API 來僅使用與其關聯的 E2 服務模型 (E2SM) 的資訊元素 (Ies)。E2SM描述了可以由Near-RT RIC和相應製程控制的E2節點中的功能。 - xApp 應註冊其產生的 API。API 生產者是 xApp 的服務是 FFS? - xApp 應能發現它們所使用的Near-RT RIC API - 平台將考慮與 xApp 相關的信任級別,例如3rd party xApp,RIC 擁有的 xApp(即 RIC 供應商提供的 xApp) ## 與xApps相關的議題 ### #1: Malicious xApps deployed on the Near-RT RIC Near-RT RIC 上的 xApp 可以從 E2 節點收集近乎即時的資訊並影響 E2 節點的行為,從而影響小區效能以及向一組 UE 或單一 UE 提供服務。 應定義載入和託管 xApp 的安全要求,以降低將未經授權、不可信或惡意 xApp 部署到近 RT RIC 的風險。 惡意 xApp 可能會被載入到Near RT RIC 上,其目的是操縱向使用者、RAN 或核心網路提供的服務或對其產生負面影響。惡意 xApp 也可能被載入到Near RT RIC 上,意圖存取、操縱或對訂戶、RAN 或核心網路的隱私產生負面影響。 ==此威脅已在 O-RAN 威脅模型 [1] 中被識別為威脅 ID T-NEAR-RT-01== 與惡意 xApp 的加入和部署相關的安全威脅包括: • 惡意xApp 未經授權存取Near-RT RIC 和E2 節點 • 惡意 xApp 濫用無線電網路資訊和對 RAN 功能的控制能力 • 影響訂戶或專用區域服務的惡意 xApp • 惡意xApp 利用UE 識別、追蹤UE 位置並更改UE 切片優先權 :::info 在xApp註冊及部署進來前都應對其進行簽章驗證 <img src="https://hackmd.io/_uploads/HyOXTlNdA.png" width=400> <img src="https://hackmd.io/_uploads/r1BVTxVdC.png" width=600> ::: --- ### #2: Compromised xApp (受損的xApp) - 安全性設定錯誤,例如已啟用但不必要的協議 - 身份驗證和授權薄弱或配置錯誤 - 不受信任的來源可能故意提供的惡意 xApp - 由可信任來源故意插入 xApp 的後門 - 攻擊者在未經事先驗證和授權的情況下透過執行注入攻擊來提交請求,以操縱配置、存取日誌、執行遠端程式碼執行等 :::info xApp映像檔應在登入時、註冊到Near-RT RIC平台時進行簽章驗證 ::: --- ### #3: Conflicting xApps xApp 可以變更 RAN 參數以最佳化特定網路指標,這可能會導致 xApp 之間的操作發生衝突。衝突的 xApp 可能會無意或惡意影響 O-RAN 系統功能,例如行動管理、存取控制、無線資源控制和負載平衡,從而降低網路的效能或可用性。 Near-RT RIC 和 E2 節點之間的功能劃分取決於可用的 xApp 和 O-gNB 公開的功能。這可能會在近 RT RIC 和 O-gNB 做出的決策之間造成可能的衝突,導致網路不穩定,從而引入可能被威脅行為者利用的漏洞。 ==此威脅已在 O-RAN 威脅模型中被識別為威脅 ID T-xApp-02== 與衝突的 xApp 相關的安全威脅包括: - 來自 xApp 的 DoS 故意創建與 gNB 內部決策相衝突的 RRM 決策 - xApp 故意創建與其他 xApp 決策相衝突的 RRM 決策導致效能下降 :::info 透過 Conflic Mitigation功能來指導 ::: --- ### #4: Isolation between xApps xApp 將與其他Near-RT RIC 平台元件進行互動,第 3 方 xApp 和 RIC 供應商提供的 xApp 部署在一起,xApp 可用於影響其他共置 xApp/Near-RT RIC 平台。 如果沒有適當的隔離,xApp 可用於: - 過度消耗所有 xApp 共享的平台資源,從而使其他共處一地的 xApp 資源不足 - 管理對其他共置 xApp 的 DoS 攻擊,並影響受攻擊的 xApp 提供的服務 - 管理對Near-RT RIC平台組件的DoS攻擊,影響Near-RT RIC的可用性 - 管理對來自 RAN 的敏感即時資訊的未經授權的訪問,Near-RT RIC 用於控制 RAN 的持久配置 - 探測託管 xApps 應用程式的底層系統中的漏洞,並使用它們來管理對另一個 xApps 和平台的攻擊 :::info 要互相溝通的xApps彼此間進行驗證,且 Near-RT RIC 平台應限制分配給 xApp 的資源,確保嘗試過度消耗資源的 xApp 被隔離 ::: --- ### #8: Onboarding untrusted xApps 將不受信任的第三方 xApp 載入到Near-RT RIC 上可能會產生嚴重的安全問題,從而損害Near-RT RIC 功能、影響其他 xApp 的可用性並對 ORAN 的整體效能產生連鎖影響。 - 如果 xApp 不是來自可信任來源或不是由可信任來源維護,則它可能包含安全漏洞或後門,可能被攻擊者利用並影響Near-RT RIC 功能 - 不受信任/未經驗證的xApp 可能會提供安全性較弱的API(驗證和授權較弱或沒有),而此類xApp 可能很容易成為攻擊者闖入並在系統中傳播攻擊的橫向移動的目標(朝向其他xApp)。 - 不受信任/未經驗證的xApp 可能會暴露比所需更多的服務,而此類xApp 可能會向攻擊者暴露較大的攻擊面,以便攻擊者闖入並獲得存取權限、操縱配置、訪問日誌、插入後門 - 不受信任/未經驗證的 xApp 可用於嗅探敏感的 UE 訊息,這些訊息可能被攻擊者或不受信任/未經驗證的 xApp 本身用於惡意目的 :::info 部署及註冊之前要進行驗證,且xApps只能讓存取的使用者執行授權的操作 ::: --- ### #9: xApp exploitation via malicious A1 policies A1傳送過來的策略帶有惡意行為,讓xApps接收後執行此錯誤策略。 錯誤的策略可能會導致: - 影響Near-RT RIC 配置 O-DU 和 O-RU 功能,透過簡單地使用回饋資料降低 RAN 效能來支援拒絕服務 (DoS) 攻擊 - 導致Near-RT RIC 隔離O-CU 中的訂閱客戶 - 引導用戶資料以隔離數據,以促進網路攻擊 :::info A1 對等互連應僅與使用 TLS 1.2 或更高版本以及 PKI X.509 憑證的可信任來源建立。 ==此項目已在進行中== ::: --- ### #12: xAppID abuse 在向Near-RT RIC平台進行請求時會需要xAppID,因此這個ID要是受信任且唯一的,否則會帶來的影響包含: - 非唯一的 xAppID 可能會導致 xApp 的錯誤識別,可能允許潛在的惡意 xApp 請求某些服務(竊取服務)、資訊(資料外洩)或更改現有資訊 - 惡意xApp可能使用分配給合法xApp的xAppID從Near-RT RIC平台請求服務或訊息 - 非唯一的 xApp ID 可能導致無法準確地將操作分配給正確的 xApp - 非唯一的 xApp ID 可能會導致難以識別環境中存在惡意 xApp --- # 論文 - [End-to-End O-RAN Security Architecture, Threat Surface, Coverage, and the Case of the Open Fronthaul](https://ieeexplore.ieee.org/document/10467183) :::info ::: - [SliceSecure: Impact and Detection of DoS/DDoS Attacks on 5G Network Slices](https://ieeexplore.ieee.org/document/10056693) :::info ::: - [Open RAN security: Challenges and opportunities](https://www.sciencedirect.com/science/article/pii/S1084804523000401) :::info 3.3.3. Intelligence The different components and mechanisms that contribute to the intelligence in the Open RAN network are the Near Realtime Radio Access Network Intelligence Controller (Near-RT-RIC), Non real-time RIC (Non-RT RIC), and machine learning (ML) algorithms. These risks are mostly specific to Open RAN as they operate on new components and new algorithms, which are currently not available. The threats related to intelligence are summarized in Table 5. ::: # 實作 [O-RAN Near-Real Time RIC Build (I-Release))](https://hackmd.io/@7W5AxfCWSOSPlsXL6DTy6g/Hy1jnTGPC) *[O-RAN Near-Real Time RIC Build (J-Release)](https://hackmd.io/@7W5AxfCWSOSPlsXL6DTy6g/HJtyLmqvC) [Attack Reproduce](https://hackmd.io/cl1KNeiAQmiJJAXtwxEwQQ?view#Attack-Reproduce) # 資源 ## O-RAN SC Confluence ### Dataset 對於一般的人工智慧/機器學習,特別是在節能方面,提供訓練資料的資料集的存在非常重要。 SIM 計畫目前建議利用 2 個數據集:一個基於義大利電信的真實網路數據,另一個基於 Viavi 幫助創建的合成數據。 [Simulated datasets](https://wiki.o-ran-sc.org/display/SIM/Simulated+datasets) #### Cell Metric | Parameter | Description | Unit | | ---- | ---- | ---- | | DRB.UEThpDl | Downlink throughput | Gbps | | DRB.UEThpUl | Uplink throughput | Gbps | | RRU.PrbUsedDl | Downlink Physical Resource Blocks (PRBs) used | N/A | | RRU.PrbUsedUl | Uplink Physical Resource Blocks (PRBs) used | N/A | | RRU.PrbAvailDl | Number of Physical Resource Blocks (PRBs) available for downlink | N/A | | RRU.PrbAvailUl | Number of Physical Resource Blocks (PRBs) available for uplink | N/A | | RRU.PrbTotUl | Total usage of Physical Resource Blocks (PRBs) on the uplink | % | | RRU.PrbTotDl | Total usage of Physical Resource Blocks (PRBs) on the downlink | % | | RRC.ConnMean | Mean number of UEs in RRC connected mode | N/A | | RRC.ConnMax | Maximum number of UEs in RRC connected mode | N/A | | QosFlow.TotPdcpPduVolumeUl | Uplink data volume (PDCP PDU) delivered from gNB-DU to gNB-CU | Mbits | | QosFlow.TotPdcpPduVolumeDl | Downlink data volume (PDCP PDU) delivered from gNB-CU to gNB-DU | Mbits | | PEE.AvgPower | Average power utilization | watts (W) | | PEE.Energy | Energy utilization | kilowatt-hours (khW) | | RRU.MaxLayerDlMimo | Average maximum scheduled layer number under MIMO scenario in DL | N/A | | CARR.AverageLayersDl | Average value of scheduled MIMO layers per PRB on the DL | N/A | | RRC.ConnEstabAtt.mo-Data | Number of UE RRC connections to the cell by "mobile oriented data" cause | N/A | | RRC.ConnEstabAtt.mo-VoiceCall | Number of UE RRC connections to the cell by "mobile oriented voice call" cause | N/A | | RRC.ConnEstabAtt.mo-VideoCall | Number of UE RRC connections to the cell by "mobile oriented video call" cause | N/A | | RRC.ConnEstabSucc.mo-Data | Number of successful UE RRC connections to the cell by "mobile oriented data" cause | N/A | | RRC.ConnEstabSucc.mo-VoiceCall | Number of successful UE RRC connections to the cell by "mobile oriented voice call" cause | N/A | | RRC.ConnEstabSucc.mo-VideoCall | Number of successful UE RRC connections to the cell by "mobile oriented video call" cause | N/A | | RRC.ConnEstabFailCause.NetworkReject | Number of unsuccessful UE RRC connections to the cell rejected by the network | N/A | #### UE Metric | Parameter | Description | Unit | | ---- | ---- | ---- | | DRB.UEThpUl | Uplink throughput | Gbps | | DRB.UECqiUl | UE's uplink CQI | N/A | | DRB.UECqiDl | UE's downlink CQI | N/A | | TB.TotNbrUl | Total number of uplink Transport Blocks (TBs) | N/A | | TB.TotNbrDl | Total number of downlink Transport Blocks (TBs) | N/A | | RRU.PrbUsedUl | Mean uplink Physical Resource Blocks (PRBs) | N/A | | RRU.PrbUsedDl | Mean downlink Physical Resource Blocks (PRBs) | N/A | | DRB.UEThpDl | Downlink throughput | Gbps | ### RIC ### xApp (範例 App) [Python 的 xApp 框架 (xapp-frame-py)](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20873778) [Go 的 xApp 框架 (xapp-frame)](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20873782) [CXX 的 xApp 框架 (xapp-frame-cpp)](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20873780) [Rust 的 xApp 框架 (xapp-frame-rust)](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=102465538) ### xApp (現有 App) [總覽(Current xApps)](https://wiki.o-ran-sc.org/display/RICA/Current+xApps) [RICAPP Project](https://wiki.o-ran-sc.org/display/IAT/RICAPP+Project) #### Github 檔案下載 [ric-app-kpimon-go](https://github.com/o-ran-sc/ric-app-kpimon-go) [ric-app-bouncer](https://github.com/o-ran-sc/ric-app-bouncer) [ric-app-ad](https://github.com/o-ran-sc/ric-app-ad) [ric-app-qp](https://github.com/o-ran-sc/ric-app-qp) [ric-app-lp](https://github.com/o-ran-sc/ric-app-lp) [ric-app-qp-aimlfw](https://github.com/o-ran-sc/ric-app-qp-aimlfw) [archived-ric-app-qp-driver](https://github.com/o-ran-sc/archived-ric-app-qp-driver)**(配合qp xApp使用)** [ric-app-mc](https://github.com/o-ran-sc/ric-app-mc)**(這個目前還沒有build,有一些問題)** ## xApp 大概念 <center><img src="https://hackmd.io/_uploads/HJoUpg4_0.png" width=400></center><br> ### xApps #### Kpimon xApp 此 xApp 是邁向 xApp 的第一步,該 xApp 透過 E2 Term 從 CU 和 DU 收集 metrics 並將其儲存在 RIC 中以供其他 xApp 使用。 #### qp xApp & qp driver xApp - **qp driver:** 主要負責讀取 SDL 的數值,並將獲得的數值給予 qp xApp。 >**D-release後已經整合進 qp xApp 中了 - **qp:** 根據 TS xApp 的需求,預估目標 UE 在附近 gNB 可得到的 UL/DL 資源。 #### ts xApp - 上圖中的 traffic steering,在部署的時候 container 會叫 `trafficxapp` - 負責進行換手的決策,並透過 RC xApp 將 control 訊息下傳到 E2 node。 #### RC xApp 負責將 control 的資訊下行到 E2 node #### Other xApps - Admission Control xApp - Measurement Campaign xApp - ML-based xApp - UE Manager xApp ### Management - Pod - **a1mediator** - **alarmmanager** - **appmgr** (= xApp manager) - **e2mgr** (= E2 manager) - **e2term** (= E2 Terminate): 涵蓋在Near-RT RIC裡面,作為RIC對E2 node的閘道,負責RIC與E2 node之間的溝通 - **o1mediator** - **rtmgr** (= routing management) - **submgr** (= subscription manager): 管理訂閱資訊,當有不同的xApp提出相同的請求時,不會重複送出 - **vespamgr** - **dbaas** (= database as a service) 目前Dbaas唯一允許的用途是為共享資料層(SDL)提供資料庫後端服務。 ## xApp 佈署 下圖為目前已建立的xApp鏡像,下方會解釋如何佈署xApp:  首先在 O-RAN 環境資料夾下載對應的 xApp 檔案 ``` cd <oran_env_file_dir> git clone https://github.com/o-ran-sc/<xApp>.git export CHART_REPO_URL=http://0.0.0.0:8090 ``` 接著尋找該 xApp 的 <config.json> 修改裡面的內容 ``` sudo vim <xApp_file_path>/<config_file>.json # Modify in config-file.json "image":{ "registry": "docker.io", "name": "cre0518/<xApp_name>", "tag": "latest" } ``` :::info 這邊以 **kpimon-go** 為例,<font color=red>紅色框框</font>修改內容如下,並記住<font color=blue>藍色框框</font> **xapp_name** 與 **version** 名字  ::: 接著對 **config.json** 與 **schema.json** 進行 onboard,並安裝xApp。 ``` dms_cli onboard ./<xApp_file_path>/<config_file>.json ./<xApp_file_path>/<config_schema>.json dms_cli install <xapp_name> <version> ricxapp ``` :::info 以**kpimon-go** 為例,上兩行指令應輸入為下: ``` dms_cli onboard ./ric-app-kpimon-go/deploy/config.json ./ric-app-kpimon-go/deploy/schema.json dms_cli install kpimon-go 2.0.2-alpha ricxapp ``` ::: | 訊息類型 | 可能幹擾的原因 | |-----------------------------|-----------------------------------------------| | RIC_E2_SETUP_REQ | E2 設定請求時,可能導致訊息排隊或資源競爭。 | | RIC_E2_SETUP_RESP | E2 設定響應處理可能會延遲,影響其他訊息的傳送。 | | RIC_E2_SETUP_FAILURE | E2 設定失敗可能觸發錯誤處理機制,佔用 RMR 資源。 | | RIC_SCTP_CONNECTION_FAILURE | SCTP 連線失敗會導致訊息重傳或中斷其他訊息的傳送。 | | RIC_SCTP_CLEAR_ALL | 清除 SCTP 連線時,會清除快取訊息,影響訊息傳遞。 | | RIC_E2_INIT | E2 初始化可能導致資源佔用,影響其他訊息的即時處理。 | | RIC_E2T_KEEP_ALIVE_REQ | 保活請求可能頻繁傳送,佔用訊息頻寬和資源。 | | RIC_E2T_KEEP_ALIVE_RESP | 保活響應如果延遲或失敗,會導致訊息處理中斷。 | | RAN_E2_RESET_REQ | RAN 重設請求可能會清除當前的傳輸狀態,影響訊息順序。 | | RAN_E2_RESET_RESP | 重設響應後可能需要重新協商,導致其他訊息處理暫停。 | | RIC_E2_RESET_REQ | RIC 重設請求會引發訊息傳遞的中斷或延遲。 | | RIC_E2_RESET_RESP | RIC 重設響應可能導致 RMR 資源暫時分配給處理此響應。 | | RAN_CONNECTED | 連線指示訊息會影響系統資源排程,幹擾其他傳輸。 | | RAN_RESTARTED | RAN 重新啟動會導致連線重建,期間其他訊息可能延遲。 | | RAN_RECONFIGURED | 重組態過程中可能需要大量處理資源,影響其他訊息。 | | RIC_RAN_E2_RESET | E2 重設訊息處理會佔用通訊資源,導致其他訊息中斷。 | | E2_TERM_KEEP_ALIVE_REQ | 保活請求過於頻繁會擠佔訊息頻寬,幹擾其他訊息。 | | E2_TERM_KEEP_ALIVE_RESP | 保活響應的延遲會影響訊息傳遞的即時性。 | | RMR_ROUTE_TABLE_UPD | 路由表更新期間,訊息轉發可能受到影響,導致延遲。 | | RIC_SERVICE_UPDATE | 服務更新操作會改變訊息處理的優先順序,影響其他訊息。 | | RIC_SERVICE_UPDATE_ACK | 服務更新確認的延遲會導致其他訊息等待。 | | RIC_SERVICE_UPDATE_FAILURE | 更新失敗會觸發錯誤處理機制,影響其他訊息流程。 | | RIC_SERVICE_QUERY | 服務查詢可能佔用訊息處理通道,影響即時性。 | | RIC_SERVICE_QUERY_ACK | 查詢確認的延遲會影響其他訊息的處理順序。 | | RIC_CONTROL_REQUEST | 控制請求的處理可能佔用大量系統資源,影響其他訊息。 | | RIC_CONTROL_FAILURE | 控制失敗會觸發重新傳送或錯誤處理,幹擾 RMR 流程。 |
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up