K.2 Application usage of SIP

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

K.2.1 Procedures at the UE

K.2.1.1 General

This subclause describes the UE SIP procedures for supporting a UE managed hosted NAT traversal approach. The description enhances the procedures specified in subclause 5.1.

K.2.1.2 Registration and authentication

K.2.1.2.1 General

The text in subclause 5.1.1.1 applies without changes.

K.2.1.2.1A Parameters contained in the ISIM

The text in subclause 5.1.1.1A applies without changes.

K.2.1.2.1B Parameters provisioned to a UE without ISIM or USIM

The text in subclause 5.1.1.1B applies without changes.

K.2.1.2.2 Initial registration

K.2.1.2.2.1 General

The procedures described in subclause 5.1.1.2.1 apply with the additional procedures described in the present subclause.

NOTE 1: In accordance with the definitions given in subclause 3.1 the IP address acquired initially by the UE in a hosted NAT scenario is the UE private IP address.

On sending a REGISTER request, the UE shall populate the header fields as indicated in subitems a) through j) of subclause 5.1.1.2 with the exceptions of subitems c) and d) which are modified as follows.

The UE shall populate:

c) a Contact header field according to the following rules: the Contact header field shall be set to include SIP URI(s) containing the private IP address or FQDN of the UE in the hostport parameter. The UE shall also include an instance ID ("+sip.instance" header field parameter) and "reg-id" header field parameter as described in RFC 5626 [92]. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for theIMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62];

d) a Via header field set to include the private IP address or FQDN of the UE in the sent-by field. For TCP, the response is received on the TCP connection on which the request was sent. For UDP, the UE shall include the "rport" header field parameter as defined in RFC 3581 [56A].

NOTE 2: The UE will learn its public IP address from the "received" header field parameter in the topmost Via header field in the 401 (Unauthorized) response to the unprotected REGISTER request.

NOTE 3: If the UE specifies a FQDN in the hostport parameter in the Contact header field and in the sent-by field in the Via header field of an unprotected REGISTER request, this FQDN will not be subject to any processing by the P-CSCF or other IMS entities.

When a 401 (Unauthorized) response to a REGISTER request is received with integrity protection the UE shall behave as described in subclause K.2.1.2.5.

When a 401 (Unauthorized) response to a REGISTER request is received and this response is received without integrity protection, the procedures described in subclause 5.1.1.2 apply with the following additions:

The UE shall compare the IP address in the "received" header field parameter with the corresponding value in the sent-by parameter in the topmost Via header field to detect if the UE is behind a NAT. If the comparison indicates that the respective values are the same, the UE concludes that it is not behind a NAT.

– if the UE is not behind a NAT the UE shall proceed with the procedures described in subclause 5.1;

– if the UE is behind a NAT the UE shall verify using the Security-Server header field that either the mechanism-name "tls" or "ipsec-3gpp" and the mode "UDP-enc-tun" is selected. If the verification succeeds the UE shall behave as described in subclause K.2.1.2.5 and store the IP address contained in the "received" header field parameter as the UE’s public IP address. If the verification does not succeed the UE shall abort the registration.

On receiving the 200 (OK) response to the REGISTER request, the procedures described in subclause 5.1.1.2 apply with the following additions:

The UE shall determine the P-CSCFs ability to support the keep-alive procedures as described in RFC 5626 [92] by checking whether the "outbound" option-tag is present in the Require header field:

– if no "outbound" option-tag is present, the UE may use some other explicit indication in order to find out whether the P-CSCF supports the outbound edge proxy functionality. Such indication may be acomplished either through UE local configuration means or the UE can examine the 200 (OK) response to its REGISTER request for Path header fields, and if such are present check whether the bottommost Path header field contains the "ob" SIP URI parameter. If the UE determines that the P-CSCF supports the outbound edge proxy functionality, the UE can use the keep-alive techniques defined in subclause K.2.1.5 and RFC 5626 [92] towards the P-CSCF; or

– if an "outbound" option-tag is present, the UE shall initiate keep-alive mechanisms as defined in subclause K.2.1.5 and RFC 5626 [92] towards the P-CSCF.

NOTE 4: Presence of the "outbound" option-tag in the Require header field indicates that both the P-CSCF and S-CSCF fully support the outbound procedures. The number of subsequent outbound registrations for the same private user identity but with a different reg-id value is based on operator policy.

K.2.1.2.2.2 Initial registration using IMS AKA

The procedures described in subclause 5.1.1.2.2 apply with the additional procedures described in the present subclause.

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.2.2 with the exceptions of the subitems which are modified as follows:

c) additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the public IP address or FQDN and the protected server port value in the sent-by field. For TCP, if the REGISTER request is protected by a security association, the UE shall include the public IP address or FQDN;

d) the Security-Client header field set to specify the security mechanisms the UE supports, the IPsec layer algorithms the UE supports and the parameters needed for the security association setup. The UE shall support the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters needed for the security association setup is specified in annex H of 3GPP TS 33.203 [19]. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in 3GPP TS 33.203 [19], and shall announce support for them according to the procedures defined in RFC 3329 [48]. In addition to transport mode, the UE shall support UDP encapsulated tunnel mode as per RFC 3948 [73A] and shall announce support for both modes as described in 3GPP TS 33.203 [19];

K.2.1.2.2.3 Initial registration using SIP digest without TLS

The procedures described in subclause 5.1.1.2.3 apply without modification.

K.2.1.2.2.4 Initial registration using SIP digest with TLS

The procedures described in subclause 5.1.1.2.4 apply without modification.

K.2.1.2.2.5 Initial registration using NASS-IMS bundled authentication

The procedures described in subclause 5.1.1.2.5 apply without modification.

K.2.1.2.3 Initial subscription to the registration-state event package

The procedures described in subclause 5.1.1.3 apply with the additional procedures described in subclause K.2.1.4.1.

K.2.1.2.4 User-initiated re-registration

K.2.1.2.4.1 General

The procedures described in subclause 5.1.1.4 apply with the additional procedures described in the present subclause.

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as indicated in subclause 5.1.1.4.1 with the exception of subitems c) and d) which are modified as follows.

The UE shall populate:

c) a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the private IP address of the UE or FQDN, its instance ID ("+sip.instance" header field parameter) along with the same "reg-id" header field parameter used for the initial, successful, registration for the given P-CSCF public identity combination as described in RFC 5626 [92]. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 [62] for the IMS communication services it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840 [62]; and

d) a Via header field according to the following rules:

– For UDP, the UE shall include the public IP address or FQDN in the sent-by field. The UE shall also include the "rport" header field parameter as defined in RFC 3581 [56A]. The UE shall only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or

– For TCP, the UE shall include the public IP address or FQDN of the UE in the sent-by field. The UE shall only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT;

When the timer F expires at the UE, the UE shall:

1) stop processing of all ongoing dialogs and transactions associated with that, if any (i.e. no further SIP signalling will be sent by the UE on behalf of these transactions or dialogs); and

2) after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2, the UE shall follow the procedures in RFC 5626 [92] to form a new flow to replace the failed one. When registering to create a new flow to replace the failed one, procedures in subclause 5.1.1.2 apply.

NOTE: These actions can also be triggered as a result of the failure of a STUN keep-alive. It is an implementation option whether these actions are also triggered by other means than expiration of timer F, e.g., based on ICMP messages.

If failed registration attempts occur in the process of creating a new flow, the flow recovery procedures defined in RFC 5626 [92] shall apply.

K.2.1.2.4.2 IMS AKA as a security mechanism

The procedures described in subclause 5.1.1.4.2 apply without modification.

K.2.1.2.4.3 SIP Digest without TLS as a security mechanism

The procedures described in subclause 5.1.1.4.3 apply without modification.

K.2.1.2.4.4 SIP Digest with TLS as a security mechanism

The procedures described in subclause 5.1.1.4.4 apply without modification.

K.2.1.2.4.5 NASS-IMS bundled authentication as a security mechanism

The procedures described in subclause 5.1.1.4.5 apply without modification.

K.2.1.2.5 Authentication

K.2.1.2.5.1 IMS AKA – general

The procedures of subclause 5.1.1.5.1 apply with the additional procedures described in the present subclause.

On receiving a 401 (Unauthorized) response to the REGISTER request and the response is deemed to be valid and signalling security is to be used, the UE shall behave as of subclause 5.1.1.5.1 with the exception of subitem 3) which is modified as follows.

The UE shall:

3) send another REGISTER request using the temporary set of security associations to protect the message. The header fields are populated as defined for the initial registration (see subclause K.2.1.2.2), with the addition that the UE shall include an Authorization header field containing the private user identity and if the "algorithm" header field parameter is "AKAv1-MD5" or "AKAv2-SHA-256", the authentication challenge response shall be calculated by the UE using RES and other parameters, as described in RFC 3310 [49] when AKAv1 is used or as described in RFC 4169 [227] when AKAv2 is used. If the "algorithm" header field parameter is "MD5" or "SHA2-256", the UE shall calculate SIP digest-response parameters as indicated in RFC 7616 [286] and RFC 8760 [287] and shall build an Authorization header field based on these parameters. The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the integrity-protected REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

NOTE: The "AKAv1-MD5" and "MD5" algorithms are only supported for backward compatibility.

For IPsec, if the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security associations. The UE should send an unprotected REGISTER request according to the procedure specified in subclause K.2.1.2.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF.

K.2.1.2.5.2 Void

K.2.1.2.5.3 IMS AKA abnormal cases

The text in subclause 5.1.1.5.3 applies without changes.

K.2.1.2.5.4 SIP digest without TLS – general

The text in subclause 5.1.1.5.4 applies without changes.

K.2.1.2.5.5 SIP digest without TLS – abnormal procedures

The procedures of subclause 5.1.1.5.5 apply with the additional procedures described in the present subclause.

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed. If performing SIP digest with TLS, the UE should send an initial REGISTER according to the procedure specified in subclause K.2.1.2.2 if the UE considers the TLS session to be no longer active at the P-CSCF.

K.2.1.2.5.6 SIP digest with TLS – general

The text in subclause 5.1.1.5.6 applies without changes.

K.2.1.2.5.7 SIP digest with TLS – abnormal procedures

The text in subclause 5.1.1.5.7 applies without changes.

K.2.1.2.5.8 NASS-IMS bundled authentication – general

The text in subclause 5.1.1.5.8 applies without changes.

K.2.1.2.5.9 NASS-IMS bundled authentication – abnormal procedures

The text in subclause 5.1.1.5.9 applies without changes.

K.2.1.2.5.10 Abnormal procedures for all security mechanisms

The text in subclause 5.1.1.5.10 applies without changes.

K.2.1.2.5A Network initiated re-authentication

The procedures of subclause 5.1.1.5A apply with the additional procedures described in the present subclause.

On starting the re-authentication procedure sending a REGISTER request that does not contain a challenge response, the UE shall behave as of subclause 5.1.1.5A with the exception of subitem 2) which is modified as follows.

The UE shall:

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in subclause 5.4.1.6) by initiating a re-registration as described in subclause K.2.1.2.4, if required.

K.2.1.2.5B Change of IPv6 address due to privacy

The text in subclause 5.1.1.5B applies without changes.

K.2.1.2.6 User-initiated deregistration

K.2.1.2.6.1 General

The procedures of subclause 5.1.1.6.1 apply with the additional procedures described in the present subclause.

On sending a REGISTER request, the UE shall populate the header fields as indicated in subclause 5.1.1.6.1 with the exception of subitems c) and d) which are modified as follows.

The UE shall populate:

c) a Contact header field set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN, its instance ID ("+sip.instance" header field parameter) along with the same "reg-id" header field parameter used for the initial, successful, registration for the given P-CSCF public identity combination as described in RFC 5626 [92];. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT;

d) a Via header field according to the following rules:

– For UDP, the UE shall include the public IP address or FQDN. The UE shall also include the "rport" header field parameter as defined in RFC 3581 [56A]. The UE shall only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or

NOTE: In case of hosted NAT traversal only the UE public IP addresses are bound to security associations or TLS session.

K.2.1.2.6.2 IMS AKA as a security mechanism

The text in subclause 5.1.1.6.2 applies without changes.

K.2.1.2.6.3 SIP digest as a security mechanism

The text in subclause 5.1.1.6.3 applies without changes.

K.2.1.2.6.4 SIP digest with TLS as a security mechanism

The text in subclause 5.1.1.6.4 applies without changes.

K.2.1.2.6.5 Initial registration using NASS-IMS bundled authentication

The text in subclause 5.1.1.6.5 applies without changes.

K.2.1.2.7 Network-initiated deregistration

The procedures of subclause 5.1.1.7 apply with the additional procedures described in the present subclause.

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as described in subclause 5.1.1.3, including one or more <registration> element(s) which were registered by this UE with:

– the state attribute set to "terminated" and the event attribute set to "rejected" or "deactivated"; or

– the state attribute set to "active" and the state attribute within the <contact> element belonging to this UE set to "terminated", and associated event attribute element to "rejected" or "deactivated";

The UE shall remove all registration details relating to these public user identities. In case of a "deactivated" event attribute, the UE shall start the initial registration procedure as described in subclause K.2.1.2.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities.

K.2.1.3 Subscription and notification

The text in subclause 5.1.2 applies without changes.

K.2.1.4 Generic procedures applicable to all methods excluding the REGISTER method

K.2.1.4.1 UE-originating case

The procedures described in subclause 5.1.2A.1 apply with the additional procedures described in the present subclause.

When the UE sends any request, the requirements in subclause 5.1.2A.1 are extended by the following requirements. The UE shall include:

– a Via header field according to the following rules:

– For UDP, the UE shall include the public IP address or FQDN and the protected server port value in the sent-by field. The UE shall also include the "rport" header field parameter as defined in RFC 3581 [56A]. The UE shall only use an FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; or

– if the request contains a Contact header field, include a Contact header field according to the following rules:

– if this is a request for a new or existing dialog, and the UE did insert a GRUU in the Contact header field, then the UE shall also include its instance ID ("+sip.instance" header field parameter), and an "ob" SIP URI parameter as described in RFC 5626 [92]; or

– if this is a request for a new or existing dialog, and the UE did not insert a GRUU in the Contact header field, then the UE shall include the public IP address of the UE or FQDN and the protected server port value bound to the security association or TLS session in the hostport parameter along with its instance ID ("+sip.instance" header field parameter), and an "ob" SIP URI parameter as described in RFC 5626 [92]. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT.

NOTE: The means to ensure that the FQDN resolves to the public IP address of the NAT are outside of the scope of this specification. One option for resolving this is local configuration.

Where a security association or TLS session exists, the UE shall discard any SIP response that is not protected by the security association or TLS session and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause K.2.1.2.

When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause K.2.1.2.4.

K.2.1.4.2 UE-terminating case

The procedures described in subclause 5.1.2A.2 apply with the additional procedures described in the present subclause.

When the UE sends any response, the requirements in subclause 5.1.2A.2 are extended by the following requirement. If the UE did not include a GRUU in the Contact header field, then the UE shall:

– include the public IP address of the UE or FQDN and the protected server port value bound to the security association or TLS session in the hostport parameter in any Contact header field that is otherwise included. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT.

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the registration and authentication procedures. The requirements on the UE within the registration and authentication procedures are defined in subclause K.2.1.2.

K.2.1.5 Maintaining flows and detecting flow failures

STUN Binding Requests are used by the UE as a keep-alive mechanism to maintain NAT bindings for signalling flows over connectionless transport (for dialogs outside a registration as well as within a registration) as well as to determine whether a flow (as described in RFC 5626 [92]) is still valid (e.g. a NAT reboot could cause the transport parameters to change). As such, the UE acts as a STUN client and shall follow the requirements defined by RFC 8489 [291]. Further, when using UDP encapsulated IPsec, the keep-alive capabilities defined within should not be used.

CRLF as defined in RFC 5626 [92] is used by the UE as a keep-alive mechanism to maintain NAT bindings for signalling flows over connection oriented transports (for dialogs outside a registration as well as within a registration) as well as to determine whether a flow (as described in RFC 5626 [92]) is still valid (e.g. a NAT reboot could cause the transport parameters to change). As such, the UE shall follow the requirements defined by RFC 5626 [92].

If the UE determines that the flow to a given P-CSCF is no longer valid (the UE does not receive a STUN reply (or CRLF) or the reply indicates a new public IP Address) the UE shall consider the flow and any associated security associations invalid and perform the initial registration procedures defined in subclause K.2.1.2.2.

When a NAT is not present, it may not be desirable to send keep-alive requests (i.e. given battery considerations for wireless UEs). As such, if a UE can reliably determine that a NAT is not present (i.e. by comparing the "received" header field parameter in the Via header field in the response to the initial un-protected REGISTER request with the locally assigned IP address) then the UE may not perform the keep-alive procedures.

K.2.1.6 Emergency services

K.2.1.6.1 General

In addition to the procedures in subclause 5.1.6.1, the following additional procedures apply. When receiving and sending requests unprotected, the UE shall transmit and receive all SIP messages using the same IP port.

K.2.1.6.2 Initial emergency registration

When a UE performs an initial emergency registration the UE shall perform the actions as specified in subclause K.2.1.2.2. The remaining procedures described in subclause 5.1.6.2 apply without modification.

K.2.1.6.2A New initial emergency registration

The text in subclause 5.1.6.2A applies without changes.

K.2.1.6.3 Initial subscription to the registration-state event package

The text in subclause 5.1.6.3 applies without changes.

K.2.1.6.4 User-initiated emergency reregistration

The UE shall perform user-initiated emergency reregistration as specified in subclause K.2.1.2.4. The remaining procedures described in subclause 5.1.6.4 apply without modification.

K.2.1.6.5 Authentication

The UE shall perform the authentication procedures as specified in subclause K.2.1.2.5. The remaining procedures described in subclause 5.1.6.5 apply without modification.

K.2.1.6.6 User-initiated emergency deregistration

The text in subclause 5.1.6.6 applies without changes.

K.2.1.6.7 Network-initiated emergency deregistration

The text in subclause 5.1.6.7 applies without changes.

K.2.1.6.8 Emergency session setup

K.2.1.6.8.1 General

The text in subclause 5.1.6.8.1 applies without changes.

K.2.1.6.8.2 Emergency session set-up in case of no registration

The text in subclause 5.1.6.8.2 applies without changes.

K.2.1.6.8.3 Emergency session set-up with an emergency registration

After a successful initial emergency registration, the UE shall apply the procedures as specified in subclause K.2.1.4, subclause 5.1.3, and subclause 5.1.4. The remaining procedures described in subclause 5.1.6.8.3 apply without modification.

K.2.1.6.8.4 Emergency session set-up within a non-emergency registration

The UE shall apply the procedures as specified in subclause K.2.1.4, subclause 5.1.3, and subclause 5.1.4. The remaining procedures described in subclause 5.1.6.8.4 apply without modification.

K.2.1.6.9 Emergency session release

The text in subclause 5.1.6.9 applies without changes.

K.2.2 Procedures at the P-CSCF

K.2.2.1 Introduction

This subclause describes the SIP procedures for supporting hosted NAT scenarios.

The description enhances the procedures specified in subclause 5.2.

K.2.2.2 Registration

K.2.2.2.1 General

The procedures described in subclause 5.2.2.1 apply without changes.

K.2.2.2.2 IMS AKA as a security mechanism

The procedures described in subclause 5.2.2.2 apply with the additional procedures described in the present subclause.

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall behave as in subclause 5.2.2.2 with the exception of subitems 2) and 3) which are modified as follows.

2) in case the REGISTER request was received without protection, then:

a) check the existence of the Security-Client header field. If the Security-Client header field is not present and signalling security is used, then the P-CSCF shall return a suitable 4xx response. If the Security-Client header field is present the P-CSCF shall:

– in case the UE indicated support for "UDP-enc-tun" then remove and store it; or

– in case the UE does not indicate support for "UDP-enc-tun" then:

– if the host portion of the sent-by field in the topmost Via header field contains an IP address that differs from the source address of the IP packet, silently drop the REGISTER request;

– otherwise continue with procedures as of subclause 5.2.2.2;

NOTE 2: If the UE does not indicate support for "UDP-enc-tun" and the P-CSCF detects that the UE is located behind a NAT device, then the P-CSCF can just drop the REGISTER request to avoid unnecessary signalling traffic.

3) in case the REGISTER request was received integrity protected, then the P-CSCF shall:

a) check the security association which protected the request. If IPsec is used and the security association is a temporary one the P-CSCF shall:

– in case the hostport parameter in the Contact address is in the form of a FQDN, ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP address bound to the security association;

– in case the P-CSCF has detected earlier that the UE is located behind a NAT and IPsec is being used, retrieve port_Uenc from the encapsulating UDP header of the packet received and complete configuration of the temporary set of security associations by configuring port_Uenc in each of the temporary security associations;

– check whether the request contains a Security-Verify header field in addition to a Security-Client header field. If there are no such header fields, then the P-CSCF shall return a suitable 4xx response. If there are such header fields, then the P-CSCF shall compare the content of the Security-Verify header field with the content of the Security-Server header field sent earlier and the content of the Security-Client header field with the content of the Security-Client header field received in the challenged REGISTER request. If those do not match, then there is a potential man-in-the-middle attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the P-CSCF shall remove the Security-Verify and the Security-Client header field;

When the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and the P-CSCF previously determined that the UE is behind a NAT and the UE indicated support for "UDP-enc-tun" IPsec mode, the P-CSCF shall:

1) delete any temporary set of security associations established towards the UE;

2) for IPsec, remove the "ck" and "ik" WWW-Authenticate header field parameters contained in the 401 (Unauthorized) response and bind the values to the proper private user identity and to the temporary set of security associations which will be setup as a result of this challenge. The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the "ck" and "ik" header field parameters have been removed;

3) insert a Security-Server header field in the response, containing the P-CSCF security list and the parameters needed.The P-CSCF shall support the setup of two pairs of security associations, as defined in 3GPP TS 33.203 [19]. The syntax of the parameters needed of the IPsec security association setup is specified in annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPSec layer algorithms for integrity protection and for encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate "UDP-enc-tun" as the only IPsec mode.

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel mode and shall leave the value for port-Uenc unspecified in each of the temporary security associations. For further details see 3GPP TS 33.203 [19] and RFC 3329 [48]. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; and

5) send the 401 (Unauthorized) response unprotected to the UE using the mechanisms described in RFC 3261 [26] and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and, in case UDP is used, to the port indicated in the "rport" header field parameter (if present) of the Via header field associated with the UE. In case TCP is used as transport protocol, the P-CSCF shall use the port on which the REGISTER request was received as client port for sending the response back to the UE.

When the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and the P-CSCF previously determined that the UE is behind a NAT and that REGISTER request was protected by an old set of security associations that use UDP encapsulated tunnel mode, the P-CSCF shall:

1) delete any temporary set of security associations established towards the UE;

2) remove the "ck" and "ik" WWW-Authenticate header field parameters contained in the 401 (Unauthorized) response and bind the values to the proper private user identity and to the temporary set of security associations which will be setup as a result of this challenge. The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the "ck" and "ik" header field parameters have been removed;

3) insert a Security-Server header field in the response, containing the P-CSCF security list and the parameters needed for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the IPsec layer algorithms for integrity protection and encryption as defined in 3GPP TS 33.203 [19]. The P-CSCF shall indicate "UDP-enc-tun" as the IPsec mode;

4) set up the temporary set of security associations with a temporary SIP level lifetime between the UE and the P-CSCF for the user identified with the private user identity. The P-CSCF shall select UDP encapsulated tunnel mode and shall specify the same port_Uenc that was used in the old set of security associations. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; and

5) send the 401 (Unauthorized) response to the UE using the old set of security associations and using the rules for sending responses as described in RFC 3261 [26] and RFC 3581 [56A], i.e. the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and if UDP is used, to the port indicated in the "rport" header field parameter (if present) of the Via header field associated with the UE. Otherwise, when the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request and:

– this response does not contain a "received" header field parameter in the Via header field associated with the UE;

– this response does not contain "rport" header field parameter in the Via header field associated with the UE and the request associated with the response was received using UDP; or

– when the P-CSCF receives a 401 (Unauthorized) response to a protected REGISTER request and that REGISTER request was protected by an old set of security associations that do not use UDP encapsulated tunnel mode;

the P-CSCF shall proceed as described in subclause 5.2.2.2 of the main body of this specification.

K.2.2.2.3 SIP digest without TLS as a security mechanism

The text in subclause 5.2.2.3 applies without changes.

K.2.2.2.4 SIP digest with TLS as a security mechanism

The procedures described in subclause 5.2.2.4 apply without changes.

K.2.2.2.5 NASS-IMS bundled authentication as a security mechanism

The text in subclause 5.2.2.5 applies without changes.

K.2.2.3 General treatment for all dialogs and standalone transactions excluding the REGISTER method

K.2.2.3.1 Requests initiated by the UE

K.2.2.3.1.1 General for all requests

The procedures described in subclause 5.2.6.3.1 apply with the additional procedures described in the present subclause.

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, the requirements are extended by the following requirements.

Before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26], the P-CSCF shall ensure that all signalling during the lifetime of the dialogue is sent over the same IMS flow set as the dialogue initiating request.

NOTE: The suggested way to ensure all signalling is sent over the same IMS flow set is to form an IMS flow token in the same way that a P-CSCF would form this for the Path header field and insert this IMS flow token in the user portion of the URI used in the record route header field value.

K.2.2.3.1.2 General for all responses

The procedures in subclause 5.2.6.3.2 apply without changes.

K.2.2.3.1.2A Abnormal cases

The text in subclause 5.2.6.3.2A applies without changes.

K.2.2.3.1.3 Initial request for a dialog

The text in subclause 5.2.6.3.3 applies without changes.

K.2.2.3.1.4 Responses to an initial request for a dialog

The text in subclause 5.2.6.3.4 applies without changes.

K.2.2.3.1.5 Target refresh request for a dialog

The text in subclause 5.2.6.3.5 applies without changes.

K.2.2.3.1.6 Responses to a target refresh request for a dialog

The text in subclause 5.2.6.3.6 applies without changes.

K.2.2.3.1.7 Request for a standalone transaction

The text in subclause 5.2.6.3.7 applies without changes.

K.2.2.3.1.8 Responses to a request for a standalone transaction

The text in subclause 5.2.6.3.8 applies without changes.

K.2.2.3.1.9 Subsequent request other than a target refresh request

The text in subclause 5.2.6.3.9 applies without changes.

K.2.2.3.1.10 Responses to a subsequent request other than a target refresh request

Void

K.2.2.3.1.11 Request for an unkown method that does not relate to an existing dialog

The text in subclause 5.2.6.3.11 applies without changes.

K.2.2.3.1.12 Responses to a request for an unkown method that does not relate to an existing dialog

Void

K.2.2.3.2 Requests terminated by the UE

K.2.2.3.2.1 General for all requests

Void

K.2.2.3.2.2 General for all responses

Void

K.2.2.3.2.3 Initial request for a dialog

The procedures described in subclause 5.2.6.4.3 apply with the additional procedures described in the present subclause.

When the P-CSCF receives, destined for the UE, a request, the requirements are extended by the following requirements. The P-CSCF shall:

– forward the request to the terminating UE over the appropriate flow within the denoted IMS flow set.

K.2.2.3.2.4 Responses to an initial request for a dialog

The text in subclause 5.2.6.4.4 applies without changes.

K.2.2.3.2.5 Target refresh request for a dialog

The procedures described in subclause 5.2.6.4.5 apply with the additional procedures described in the present subclause.

When the P-CSCF receives, destined for the UE, a request, the requirements are extended by the following requirements. The P-CSCF shall:

– forward the request to the terminating UE over the appropriate flow within the denoted IMS flow set.

K.2.2.3.2.6 Responses to a target refresh request for a dialog

The text in subclause 5.2.6.4.6 applies without changes.

K.2.2.3.2.7 Request for a standalone transaction

The procedures described in subclause 5.2.6.4.7 apply with the additional procedures described in the present subclause.

When the P-CSCF receives, destined for the UE, a request, the requirements are extended by the following requirements. The P-CSCF shall:

– forward the request to the terminating UE over the appropriate flow within the denoted IMS flow set.

K.2.2.3.2.8 Responses to a request for a standalone transaction

The text in subclause 5.2.6.4.8 applies without changes.

K.2.2.3.2.9 Subsequent request other than a target refresh request

The procedures described in subclause 5.2.6.4.9 apply with the additional procedures described in the present subclause.

When the P-CSCF receives, destined for the UE, a request, the requirements are extended by the following requirements. The P-CSCF shall:

– forward the request to the terminating UE over the appropriate flow within the denoted IMS flow set.

K.2.2.3.2.10 Responses to a subsequent request other than a target refresh request

The text in subclause 5.2.6.4.10 applies without changes.

K.2.2.3.2.11 Request for an unknown method that does not relate to an existing dialog

Void

K.2.2.3.2.12 Responses to a request for an unknown method that does not relate to an existing dialog

Void

K.2.2.4 Void

K.2.2.5 Emergency services

K.2.2.5.1 General

The procedures described in subclause 5.2.10.1 apply without changes.

K.2.2.5.2 General treatment for all dialogs and standalone transactions excluding the REGISTER method – from an unregistered user

The procedures described in subclause 5.2.10.2 apply with the additional procedures described in the present subclause.

When the P-CSCF receives from the UE an initial request for a dialog or a request for a standalone transaction, the requirements are extended by the following requirements.

K.2.2.5.3 General treatment for all dialogs and standalone transactions excluding the REGISTER method after emergency registration

The procedures described in subclause 5.2.10.3 apply with the additional procedures described in the present subclause.

When the P-CSCF receives from the UE an initial request for a dialog, or a standalone transaction, or an unknown method, the following requirements:

1) include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], if necessary, and execute the procedure described in step 4, 5, 6, and 7, in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11, subclause 5.2.7.2 and subclause K.2.2.3.1, as appropriate. An additional sub-service type can be added if information on the type of emergency service is known. The entry in the Request-URI that the P-CSCF includes may either be:

– as received from the UE in the Request-URI in accordance with RFC 5031 [69]; or

– as deduced from the Request-URI received from the UE.

K.2.2.5.4 General treatment for all dialogs and standalone transactions excluding the REGISTER method – non-emergency registration

The procedures described in subclause 5.2.10.4 apply with the additional procedures described in the present subclause.

When the P-CSCF receives from the UE an initial request for a dialog, or a standalone transaction, or an unknown method, the following requirements are extended:

1) include in the Request-URI an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], if necessary, and execute the procedure described in step 3, 4, 5, 6, and 7, in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 subclause 5.2.7.2 and subclause K.2.2.3.1, as appropriate. An additional sub-service type can be added if information on the type of emergency service is known. The entry in the Request-URI that the P-CSCF includes may either be:

– as received from the UE in the Request-URI in accordance with RFC 5031 [69]; or