Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
K Additional procedures in support of UE managed NAT traversal  K.1 Scope  K.2 Application usage of SIP  K.3 Application usage of SDP  K.5 Application usage of ICE 
...

 

K (Normative)  Additional procedures in support of UE managed NAT traversal |R7|  p. 863

K.1  Scope  p. 863

This Annex describes the UE, P-CSCF, and S-CSCF procedures in support of UE managed NAT traversal. For ICE, the IBCF procedures are also described. In this scenario, both the media flows and the SIP signalling both traverse a NA(P)T device located in the customer premises domain. The term "hosted NAT" is used to address this function. This Annex does not consider the case where the NAT is behind the P-CSCF as different NAT traversal procedures are necessary for this architectural scenario.
The procedures described in this subclause of this Annex rely on the UE to manage the NAT traversal process. As part of the UE management process, the UE can learn whether it is behind a NAT or not, and choose whether the proceedures in this Annex are applied or not.
The protection of SIP messages is provided by applying either UDP encapsulation to IPSec packets in accordance with RFC 3948 and as defined in TS 33.203 or by utilizing TLS as defined in TS 33.203.
Up

K.2  Application usage of SIP  p. 863

K.2.1  Procedures at the UE  p. 863

K.2.1.1  General  p. 863

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  p. 863

K.2.1.2.1  General  p. 863
The text in subclause 5.1.1.1 applies without changes.
K.2.1.2.1A  Parameters contained in the ISIM  p. 863
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 |R8|  p. 863
The text in subclause 5.1.1.1B applies without changes.
K.2.1.2.2  Initial registration  p. 864
K.2.1.2.2.1  General   p. 864
The procedures described in subclause 5.1.1.2.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 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. 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 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;
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.
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 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 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 towards the P-CSCF.
Up
K.2.1.2.2.2  Initial registration using IMS AKA   p. 865
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 TS 33.203. The syntax of the parameters needed for the security association setup is specified in annex H of TS 33.203. The UE shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The UE shall support the IPsec layer algorithms for integrity and confidentiality protection as defined in TS 33.203, and shall announce support for them according to the procedures defined in RFC 3329. In addition to transport mode, the UE shall support UDP encapsulated tunnel mode as per RFC 3948 and shall announce support for both modes as described in TS 33.203;
Up
K.2.1.2.2.3  Initial registration using SIP digest without TLS   p. 865
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   p. 865
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   p. 865
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  p. 865
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 reregistration  p. 865
K.2.1.2.4.1  General   p. 865
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. 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 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; 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. 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 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.
If failed registration attempts occur in the process of creating a new flow, the flow recovery procedures defined in RFC 5626 shall apply.
Up
K.2.1.2.4.2  IMS AKA as a security mechanism   p. 866
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   p. 866
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   p. 866
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   p. 866
The procedures described in subclause 5.1.1.4.5 apply without modification.
K.2.1.2.5  Authentication  p. 866
K.2.1.2.5.1  IMS AKA - general  p. 866
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 when AKAv1 is used or as described in RFC 4169 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 and RFC 8760 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.
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.
Up
K.2.1.2.5.2  Void
K.2.1.2.5.3  IMS AKA abnormal cases  p. 867
The text in subclause 5.1.1.5.3 applies without changes.
K.2.1.2.5.4  SIP digest without TLS - general   p. 867
The text in subclause 5.1.1.5.4 applies without changes.
K.2.1.2.5.5  SIP digest without TLS - abnormal procedures   p. 867
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.
Up
K.2.1.2.5.6  SIP digest with TLS - general   p. 867
The text in subclause 5.1.1.5.6 applies without changes.
K.2.1.2.5.7  SIP digest with TLS - abnormal procedures   p. 867
The text in subclause 5.1.1.5.7 applies without changes.
K.2.1.2.5.8  NASS-IMS bundled authentication - general   p. 867
The text in subclause 5.1.1.5.8 applies without changes.
K.2.1.2.5.9  NASS-IMS bundled authentication - abnormal procedures   p. 867
The text in subclause 5.1.1.5.9 applies without changes.
K.2.1.2.5.10  Abnormal procedures for all security mechanisms   p. 867
The text in subclause 5.1.1.5.10 applies without changes.
K.2.1.2.5A  Network-initiated re-authentication |R8|  p. 867
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 reregistration as described in subclause K.2.1.2.4, if required.
Up
K.2.1.2.5B  Change of IPv6 address due to privacy |R8|  p. 868
The text in subclause 5.1.1.5B applies without changes.
K.2.1.2.6  User-initiated deregistration  p. 868
K.2.1.2.6.1  General   p. 868
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. 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. 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;
Up
K.2.1.2.6.2  IMS AKA as a security mechanism   p. 868
The text in subclause 5.1.1.6.2 applies without changes.
K.2.1.2.6.3  SIP digest as a security mechanism   p. 868
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   p. 868
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   p. 868
The text in subclause 5.1.1.6.5 applies without changes.
K.2.1.2.7  Network-initiated deregistration  p. 868
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.
Up

K.2.1.3  Subscription and notification  p. 869

The text in subclause 5.1.2 applies without changes.

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

K.2.1.4.1  UE-originating case  p. 869
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. 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; and
  • 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; 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. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT.
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.
Up
K.2.1.4.2  UE-terminating case  p. 869
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.
Up

K.2.1.5  Maintaining flows and detecting flow failures  p. 870

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) 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. Further, when using UDP encapsulated IPsec, the keep-alive capabilities defined within should not be used.
CRLF as defined in RFC 5626 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) 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.
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.
Up

K.2.1.6  Emergency services  p. 870

K.2.1.6.1  General  p. 870
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  p. 870
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  p. 870
The text in subclause 5.1.6.2A applies without changes.
K.2.1.6.3  Initial subscription to the registration-state event package |R17|  p. 870
The text in subclause 5.1.6.3 applies without changes.
K.2.1.6.4  User-initiated emergency reregistration  p. 870
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  p. 870
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  p. 871
The text in subclause 5.1.6.6 applies without changes.
K.2.1.6.7  Network-initiated emergency deregistration  p. 871
The text in subclause 5.1.6.7 applies without changes.
K.2.1.6.8  Emergency session setup  p. 871
K.2.1.6.8.1  General  p. 871
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  p. 871
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  p. 871
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.
Up
K.2.1.6.8.4  Emergency session set-up within a non-emergency registration  p. 871
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.
Up
K.2.1.6.9  Emergency session release  p. 871
The text in subclause 5.1.6.9 applies without changes.

K.2.2  Procedures at the P-CSCF  p. 871

K.2.2.1  Introduction  p. 871

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  p. 871

K.2.2.2.1  General |R8|  p. 871
The procedures described in subclause 5.2.2.1 apply without changes.
K.2.2.2.2  IMS AKA as a security mechanism |R8|  p. 871
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:
  1. 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;
3) in case the REGISTER request was received integrity protected, then the P-CSCF shall:
  1. 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 TS 33.203. The syntax of the parameters needed of the IPsec security association setup is specified in annex H of TS 33.203. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The P-CSCF shall support the IPSec layer algorithms for integrity protection and for encryption as defined in TS 33.203. 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 TS 33.203 and RFC 3329. 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 and RFC 3581, 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 TS 33.203. The P-CSCF shall support the "ipsec-3gpp" security mechanism, as specified in RFC 3329. The P-CSCF shall support the IPsec layer algorithms for integrity protection and encryption as defined in TS 33.203. 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 and RFC 3581, 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.
Up
K.2.2.2.3  SIP digest without TLS as a security mechanism |R8|  p. 873
The text in subclause 5.2.2.3 applies without changes.
K.2.2.2.4  SIP digest with TLS as a security mechanism |R8|  p. 873
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 |R8|  p. 873
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  p. 874

K.2.2.3.1  Requests initiated by the UE  p. 874
K.2.2.3.1.1  General for all requests   p. 874
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, 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.
Up
K.2.2.3.1.2  General for all responses   p. 874
The procedures in subclause 5.2.6.3.2 apply without changes.
K.2.2.3.1.2A  Abnormal cases   p. 874
The text in subclause 5.2.6.3.2A applies without changes.
K.2.2.3.1.3  Initial request for a dialog   p. 874
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   p. 874
The text in subclause 5.2.6.3.4 applies without changes.
K.2.2.3.1.5  Target refresh request for a dialog   p. 874
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   p. 874
The text in subclause 5.2.6.3.6 applies without changes.
K.2.2.3.1.7  Request for a standalone transaction   p. 874
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   p. 874
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   p. 874
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   p. 874
Void
K.2.2.3.1.11  Request for an unkown method that does not relate to an existing dialog   p. 875
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   p. 875
Void
K.2.2.3.2  Requests terminated by the UE  p. 875
K.2.2.3.2.1  General for all requests   p. 875
Void
K.2.2.3.2.2  General for all responses   p. 875
Void
K.2.2.3.2.3  Initial request for a dialog   p. 875
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   p. 875
The text in subclause 5.2.6.4.4 applies without changes.
K.2.2.3.2.5  Target refresh request for a dialog   p. 875
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   p. 875
The text in subclause 5.2.6.4.6 applies without changes.
K.2.2.3.2.7  Request for a standalone transaction   p. 875
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   p. 875
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   p. 875
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   p. 876
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   p. 876
Void
K.2.2.3.2.12  Responses to a request for an unknown method that does not relate to an existing dialog   p. 876
Void

K.2.2.4  Void

K.2.2.5  Emergency services  p. 876

K.2.2.5.1  General  p. 876
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  p. 876
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.
Before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261, 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.
Up
K.2.2.5.3  General treatment for all dialogs and standalone transactions excluding the REGISTER method after emergency registration  p. 876
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, 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; or
    • as deduced from the Request-URI received from the UE.
Up
K.2.2.5.4  General treatment for all dialogs and standalone transactions excluding the REGISTER method - non-emergency registration  p. 877
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, 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; or
    • as deduced from the Request-URI received from the UE; and
Up
K.2.2.5.5  Abnormal cases  p. 877
The text in subclause 5.2.10.5 applies without changes.

K.2.3  Void

K.2.4  Void

K.3  Application usage of SDP  p. 877

K.3.1  UE usage of SDP  p. 877

The procedures as of subclause 6.1 apply.

K.3.2  P-CSCF usage of SDP  p. 877

The procedures as of subclause 6.2 apply.

K.4  Void

K.5  Application usage of ICE  p. 877

K.5.1  Introduction  p. 877

The following subclauses describe the usage of the Interactive Connectivity Establishment (ICE) procedures as documented in RFC 8445 and RFC 8839.

K.5.2  UE usage of ICE  p. 878

K.5.2.1  General  p. 878

NAT bindings also need to be kept alive for media. RFC 8445 provides requirements for STUN based keepalive mechanisms. UEs that do not implement the ICE procedures as defined in RFC 8445 should implement the keepalive procedures defined in RFC 8445. In the case where keepalives are required and the other end does not support ICE (such that STUN cannot be used for a keepalive) or the UE can not discover STUN or TURN servers to gather candidates, the UE shall send an empty (no payload) RTP packet with a payload type of 20 as a keepalive as long as the other end has not negotiated the use of this value. If this value has already been negotiated, then some other unused static payload type from table 5 of RFC 3551 shall be used. When sending an empty RTP packet, the UE shall continue using the sequence number (SSRC) and timestamp as the negotiated RTP steam.
Up

K.5.2.2  Call initiation - UE-origination case  p. 878

The UE should support the agent requirements for ICE as defined by RFC 8445 when sending the initial INVITE request. RFC 8445 and RFC 8839 provide procedures for:
  1. Gathering candidate addresses for RTP and RTCP prior to sending the INVITE;
  2. Encoding the candidate addresses in the SDP that is included with the INVITE;
  3. Acting as a STUN server to receive binding requests from the remote client when it does connectivity checks;
  4. Performing connectivity checks on received candidate addresses for RTP and RTCP;
  5. Determining and possibly selecting a better active address based on the requirements in RFC 8445 and RFC 8839;
  6. Subsequent offer/answer exchanges; and
  7. Sending media.
When supporting the ICE procedures, the UE shall also support the STUN agent requirements as described in RFC 8489 in order to gather STUN addresses, the TURN client requirements as described in RFC 8656 in order to gather TURN Server addresses and the STUN Server requirements defined in RFC 8445 as well as the requirements for STUN Servers defined in RFC 8489 for responding to connectivity checks.
RFC 8445 provides an algorithm for determining the priority of a particular candidate. The following additional requirements are provided to the UE:
  1. The type preference assigned for each type of candidate from least to highest should be: Relayed Transport Address, STUN address, local address; and
  2. If the UE has a dual IPv4/IPv6 stack, IPv6 addresses may be assigned a higher local preference than IPv4 addresses based on the operator's policy.
RFC 8445 provides guidance on choosing the in-use candidate and recommends that a UE choose relayed candidates as the in-use address. The following additional requirements are provided to the UE:
  1. If a TURN server is available, the Relayed Transport Address should be used as the initial active transport address (i.e. as advertised in the m/c lines of the SDP); and
  2. If a TURN server is not available, an address obtained via STUN should be used as the initial active transport address.
Regardless of whether the UE supports the above procedures, the UE shall, upon receipt of an SDP answer with candidate addresses, perform connectivity checks on the candidate addresses as described in RFC 8445 and RFC 8839. In order to perform connectivity checks, the UE shall act as a STUN client as defined in RFC 8489. Further, the UE shall also follow the procedures in RFC 8445 and RFC 8839 when sending media.
Up

K.5.2.3  Call termination - UE-termination case  p. 879

The UE should support agent requirements for ICE as defined by RFC 8445 when receiving an initial INVITE request. RFC 8445 and RFC 8839 provide procedures for:
  1. Gathering candidate addresses for RTP and RTCP prior to sending the answer as described in RFC 8445;
  2. Encoding the candidate addresses in the SDP answer as described in RFC 8839;
  3. Acting as a STUN server to receive binding requests from the remote client when it does connectivity checks;
  4. Performing connectivity checks on received candidate addresses for RTP and RTCP;
  5. Determining and possibly selecting a better active address based on the requirements in RFC 8445 and RFC 8839;
  6. Subsequent offer/answer exchanges; and
  7. Sending media.
When supporting the ICE procedures, the UE shall also support the STUN agent requirements as described in RFC 8489 in order to gather STUN addresses, the TURN client requirements as described in RFC 8656 in order to gather TURN Server addresses and the STUN Server requirements defined in RFC 8445 as well as the requirements for STUN Servers defined in RFC 8489 for responding to connectivity checks.
RFC 8445 provides an algorithm for determining the priority of a given candidate. The additional requirements for the UE:
  1. The priority of candidate addresses from least to highest should be: Relayed Transport Address, STUN address, local address; and
  2. If the UE has a dual IPv4/IPv6 stack, IPv6 addresses MAY be placed at a higher priority than IPV4 addresses based on the operator's policy.
RFC 8445 provides guidance on choosing the in-use candidate and recommends that a UE choose relayed candidates as the in-use address. The following additional requirements are provided to the UE:
  1. If a TURN server is available, the Relayed Transport Address should be used as the initial active transport address (i.e. as advertised in the m/c lines of the SDP); and
  2. If a TURN server is not available, an address obtained via STUN should be used as the initial active transport address.
Regardless of whether the UE supports the above procedures, the UE shall, upon receipt of an SDP offer with candidate addresses, perform connectivity checks on the candidate addresses as described in RFC 8445 and RFC 8839. In order to perform connectivity checks, the UE shall act as a STUN client as defined in RFC 8489. Further, the UE shall also follow the procedures in RFC 8445 and RFC 8839 when sending media.
When receiving an SDP offer which does not indicate support for ICE, the UE aborts the ICE procedures and reverts to RFC 3264 offer/answer procedures; per RFC 8445 and RFC 8839. However, if the terminating UE is behind a NA(P)T device this may result in the inability to pass media for the session as the terminating UE will respond with its locally assigned IP address which is unreachable. In order to ensure successful media exchange, the terminating UE shall provide either a STUN derived IP address and port or a TURN provided IP address and port in the m/c lines of the SDP answer. If the provided address and port is a TURN address and port, the policy charging and control framework will be unable to establish proper filter criteria as the address is that of the TURN server and not that of the UE or NAT in front of the UE; see Section B.3 of RFC 8445 for further details. To rectify this issue, the terminating UE shall also include a candidate attribute as described in RFC 8445 and RFC 8839 identifying the server reflexive IP address and port (i.e. the IP address and port on the public side of the NAT) used when a TURN provided address and port is provided in the m/c line of the SDP answer.
Up

K.5.3  P-CSCF support of ICE |R8|  p. 880

The P-CSCF procedures to support ICE as specified in RFC 8445 and RFC 8839 are defined in subclause 6.7.2.7.

K.5.4  Void

Up   Top   ToC