C.2.2 When https URI scheme is used

29.5733GPP5G SystemPublic Land Mobile Network (PLMN) InterconnectionRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

C.2.2.1 General

The following figures show the end to end call flow between an NF service consumer and a NF service producer in different PLMNs when:

– the SEPP in each PLMN acts as a security proxy;

– the negotiated security policy between the SEPPs is TLS;

– "https" scheme URI is used between the NF service consumer and NF service producer;

– "https" scheme URI is used for accessing NRF’s NF discovery service; and

– TLS protection between NF and SEPP relies on using telescopic FQDN or 3gpp-Sbi-Target-apiRoot header.

C.2.2.2 With TLS protection between NF and SEPP relying on telescopic FQDN, and TLS security without the 3gpp-Sbi-Target-apiRoot header used over N32f

Figure C.2.2.2-1: End to end call flow when https scheme URI is used, telescopic FQDNs are used between NF and SEPP and TLS security without the 3gpp-Sbi-Target-apiRoot header is used between SEPPs

1. The SEPP on the NF service consumer side (c-SEPP) and the SEPP on the NF service producer side (p-SEPP) negotiate the security capabilities using the procedure specified in clause 5.2.2. The SEPPs mutually negotiate to use TLS as the security policy.

2. A TLS connection is setup between the c-SEPP and the p-SEPP for N32-f forwarding.

3. Before the NF service consumer starts using the API of the NF service producer it needs to discover the NF service profile of the producer by querying the NRF. The NF service consumer uses "https" scheme URI to access the Nnrf_NFDiscovery service. This implies that the NF service consumer sets up a TLS connection to the c-NRF and then sends the HTTP request over the TLS connection to the c-NRF.

4. The NRF on the NF service consumer side (c-NRF) needs to further initiate a discovery request to the NRF on the NF service producer side (p-NRF). The c-NRF uses "https" scheme URI to access the NF discovery service of the p-NRF. Since "https" requires setup of TLS connection with the p-NRF and it requires that c-NRF has to verify that the certificate presented by the endpoint of the TLS connection belongs to the authoritative server of the p-NRF, a telescopic FQDN with wildcarded certificate scheme mechanism is specified in 3GPP TS 33.501 [6]. The c-NRF is configured with the telescopic FQDN of the p-NRF with the telescopic FQDN having the FQDN of the c-SEPP as the trailing part. The c-NRF sets up a TLS connection with the authoritative server for the telescopic FQDN (i.e. the c-SEPP).

5. The c-NRF forwards the NF discovery request in this TLS connection.

6. The c-SEPP extracts the NF discovery request from the TLS connection, replaces the telescopic FQDN in the request URI with the FQDN of the p-NRF and sends the request towards p-SEPP in the TLS tunnel setup in step 2. The c-SEPP and the p-SEPP act as a man in the middle proxy in this case.

7. The p-SEPP extracts the HTTP message received on the TLS connection, and then seeing that the URI scheme of the NF discovery service of the p-NRF is in the request URI "https", the p-SEPP sets up a TLS connection with the p-NRF.

8. The p-SEPP forwards the NF discovery request to the p-NRF.

9. The p-NRF sends the NF discovery response within the TLS connection. The NF service profile contains service URI with "https" scheme. The FQDN of the NF service is an inter PLMN FQDN.

10. The p-SEPP forwards the NF discovery response within TLS tunnel setup in step 2 to the c-SEPP. The p-SEPP may replace the inter PLMN FQDN of the NF service producer’s API endpoint with a label representing that FQDN. The p-SEPP re-maps the label with the NF service producer’s API endpoint in step 17.

11. The c-SEPP upon receiving the HTTP response message for NF discovery response, within the TLS tunnel in step 2, replaces the trailing part of the inter PLMN FQDN of the NF service producer’s API endpoint in the NF service profile with the FQDN of the c-SEPP, to form a telescopic FQDN as specified in clause 28.5.2 of 3GPP TS 23.003 [19]. The c-SEPP may replace the label part of the telescopic FQDN with a label of it’s own significance. The p-SEPP re-maps the label in step 16.

12. The c-SEPP then forwards the NF discovery response to c-NRF, with the NF service profile containing the telescopic FQDN.

13. The c-NRF sends the NF discovery response to NF service consumer.

14. The NF service profile received at the NF service consumer contains service URI with "https" scheme. The NF service consumer sets up a TLS connection with the authoritative server for the telescopic FQDN (i.e. c-SEPP) received in step 13.

15. The NF service consumer sends the HTTP service request within the TLS connection to the c-SEPP.

16. The c-SEPP extracts the HTTP request from the TLS connection, replaces the telescopic FQDN in the request URI the FQDN of the NF service producer and sends the request towards p-SEPP in the TLS tunnel setup in step 2. The c-SEPP and the p-SEPP act as a man in the middle proxy in this case.

17. The p-SEPP extracts the HTTP message received on the TLS connection, and then seeing that the URI scheme of the NF service producer in the request URI is "https", the p-SEPP sets up a TLS connection with the NF service producer. The p-SEPP also replaces callback URI and link relations within the extracted HTTP message with a telescopic FQDN containing the FQDN of the p-SEPP as the trailing part, as specified in clause 6.1.4.3 of 3GPP TS 29.500 [4].

18. The p-SEPP forwards the HTTP request to the NF service producer.

19. The NF service producer sends the HTTP response within the TLS connection.

20. The p-SEPP forwards the HTTP response within TLS tunnel setup in step 2 to the c-SEPP.

21. The c-SEPP upon receiving the HTTP response message within the TLS tunnel setup in step 2, forwards the response to the NF service consumer. The c-SEPP replaces callback URI and link relations within the extracted HTTP response message with a telescopic FQDN containing the FQDN of the c-SEPP as the trailing part, as specified in clause 6.1.4.3 of 3GPP TS 29.500 [4].

C.2.2.3 With TLS protection between NF and SEPP relying on 3gpp-Sbi-Target-apiRoot header, and TLS security without the 3gpp-Sbi-Target-apiRoot header used over N32f

Figure C.2.2.3-1 End to end call flow when https scheme URI is used, 3gpp-Sbi-Target-apiRoot header is used between NF and SEPP and TLS security without the 3gpp-Sbi-Target-apiRoot header is used between SEPPs

1. Same as step 1 of Figure C.2.2.2-1.

2. Same as step 2 of Figure C.2.2.2-1.

3. Same as step 3 of Figure C.2.2.2-1

4. The NRF on the NF service consumer side (c-NRF) needs to further initiate a discovery request to the NRF on the NF service producer side (p-NRF). The c-NRF uses "https" scheme URI to access the NF discovery service of the p-NRF. The c-NRF setups a TLS connection with the authoritative server for the SEPP FQDN (in the apiRoot of the Request URI) and verifies that the certificate presented by the endpoint of the TLS connection belongs to the authoritative server of the c-SEPP. The c-NRF is configured with the c-SEPP FQDN, or the c-SEPP registered to the c-NRF (including c-SEPP FQDN in its profile).

5. The c-NRF forwards the NF discovery request in this TLS connection, including an 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the p-NRF.

6. The c-SEPP extracts the NF discovery request from the TLS connection, replaces the apiRoot of the SEPP FQDN in the request URI with the apiRoot of the p-NRF received in the 3gpp-Sbi-Target-apiRoot header and sends the request towards p-SEPP in the TLS tunnel setup in step 2. The c-SEPP and the p-SEPP act as a man in the middle proxy in this case.

7. The p-SEPP extracts the HTTP message received on the TLS connection, and then seeing that the URI scheme of the NF discovery service of the p-NRF is "https", the p-SEPP sets up a TLS connection with the p-NRF.

8. Same as step 8 of Figure C.2.2.2-1

9. Same as step 9 of Figure C.2.2.2-1

10. Same as step 10 of Figure C.2.2.2-1

11, 12. The c-SEPP forwards the NF discovery response to c-NRF.

13. Same as step 13 of Figure C.2.2.2-1

14. The NF service profile received at the NF service consumer contains service URI with "https" scheme. Since the URI of the p-NF contains an authority of a remote PLMN, the NF service consumer sets up a TLS connection with the authoritative server for the SEPP FQDN (i.e. c-SEPP). The c-NF is configured with the c-SEPP FQDN, or the c-NF discovers the c-SEPP FQDN by querying the c-NRF.

15. The NF service consumer sends the HTTP service request within the TLS connection to the c-SEPP, including a 3pp-Sbi-Target-apiRoot header set to the apiRoot of the p-NF.

16. The c-SEPP extracts the HTTP request from the TLS connection, replaces the apiRoot of the SEPP FQDN in the request URI with the apiRoot of the p-NRF received in the 3gpp-Sbi-Target-apiRoot header and sends the request towards p-SEPP in the TLS tunnel setup in step 2. The c-SEPP and the p-SEPP act as a man in the middle proxy in this case.

17. The p-SEPP extracts the HTTP message received on the TLS connection and then seeing that the URI scheme of the NF service producer is "https", the p-SEPP sets up a TLS connection with the NF service producer.

18. Same as step 18 of Figure C.2.2.2-1

19. Same as step 19 of Figure C.2.2.2-1

20. Same as step 20 of Figure C.2.2.2-1

21. The c-SEPP upon receiving the HTTP response message within the TLS tunnel setup in step 2, forwards the response to the NF service consumer.

C.2.2.4 With TLS protection between NF and SEPP relying on telescopic FQDN, and TLS security with the 3gpp-Sbi-Target-apiRoot header used over N32f

Figure C.2.2.4-1: End to end call flow when https scheme URI is used, telescopic FQDNs are used between NF and SEPP and TLS security with the 3gpp-Sbi-Target-apiRoot header is used between SEPPs

1. Same as step 1 of Figure C.2.2.2-1.

2. Same as step 3 of Figure C.2.2.2-1.

3. Same as step 4 of Figure C.2.2.2-1.

4. Same as step 5 of Figure C.2.2.2-1

5. The c-SEPP setups a TLS connection with the authoritative server for the p-SEPP FQDN (in the apiRoot of the Request URI) and verifies that the certificate presented by the endpoint of the TLS connection belongs to the authoritative server of the p-SEPP. The c-SEPP is configured with the p-SEPP FQDN.

6. The c-SEPP sets the apiRoot in the request URI with the apiRoot of the p-SEPP, inserts the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the p-NRF derived from the telescopic FQDN received in step 4, and sends the request towards p-SEPP.

7. The p-SEPP extracts the HTTP message received on the TLS connection, replaces the apiRoot of the p-SEPP FQDN in the request URI with the apiRoot of the p-NRF received in the 3gpp-Sbi-Target-apiRoot header, and then seeing that the URI scheme of the NF discovery service of the p-NRF is "https", the p-SEPP sets up a TLS connection with the p-NRF.

8 to 15. Same as steps 8 to 15 of Figure C.2.2.3-1.

16. The c-SEPP extracts the HTTP request from the TLS connection, sets the apiRoot of the p-SEPP FQDN in the request URI, inserts the 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the p-NF derived from the telescopic FQDN received in step 15, and sends the request towards p-SEPP.

17. The p-SEPP extracts the HTTP message received on the TLS connection, replaces the apiRoot of the p-SEPP FQDN in the request URI with the apiRoot of the p-NF received in the 3gpp-Sbi-Target-apiRoot header and then seeing that the URI scheme of the NF service producer is "https", the p-SEPP sets up a TLS connection with the NF service producer.

18 to 21. Same as steps 18 to 21 of Figure C.2.2.2-1

C.2.2.5 With TLS protection between NF and SEPP relying on 3gpp-Sbi-Target-apiRoot header, and TLS security with the 3gpp-Sbi-Target-apiRoot header used over N32f

Figure C.2.2.5-1: End to end call flow when https scheme URI is used, 3gpp-Sbi-Target-apiRoot header is used between NF and SEPP and TLS security with the 3gpp-Sbi-Target-apiRoot header is used between SEPPs

1. Same as step 1 of Figure C.2.2.3-1.

2. Same as step 3 of Figure C.2.2.3-1

3. Same as step 4 of Figure C.2.2.3-1

4. Same as step 5 of Figure C.2.2.3-1.

6. The c-SEPP sets the apiRoot in the request URI with the apiRoot of the p-SEPP and sends the request towards p-SEPP including the 3gpp-Sbi-Target-apiRoot header received in step 4.

8 to 15. Same as steps 8 to 15 of Figure C.2.2.3-1.

16. The c-SEPP extracts the HTTP request from the TLS connection, replaces the apiRoot of the c-SEPP FQDN in the request URI with the apiRoot of the p-SEPP, and sends the request towards p-SEPP including the 3gpp-Sbi-Target-apiRoot header received in step 15.

18 to 21. Same as steps 18 to 21 of Figure C.2.2.2-1