Tech-invite  3GPPspace  IETF RFCs  SIP
Quick  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.0.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… 
F Additional procedures in support for hosted NAT  F.1 Scope  F.2 Application usage of SIP  F.2.1 UE usage of SIP  F.2.2 P-CSCF usage of SIP  F.2.3 S-CSCF usage of SIP  F.4 P-CSCF usage of SIP in case UDP encapsulated IPsec is not employed  F.4.1 Introduction  F.4.2 Registration  F.4.3 General treatment for all dialogs and standalone transactions excluding the REGISTER method  F.5 NAT traversal for media flows 
...

 

F (Normative)  Additional procedures in support for hosted NAT |R7|  p. 832

F.1  Scope  p. 832

This Annex describes the UE and P-CSCF procedures in support of hosted NAT. 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.
When receiving an initial SIP REGISTER request without integrity protection, the P-CSCF can, determine whether to perform the hosted NAT procedures for the user identified by the REGISTER request by comparing the address information in the top-most SIP Via header field with the IP level address information from where the request was received. The P-CSCF will use the hosted NAT procedure only when the address information do not match.
In order to provide hosted NAT traversal for SIP REGISTER requests without integrity protection and the associated responses, the P-CSCF makes use of the "received" header field parameter as described in RFC 3261 and, in addition, if UDP is used, makes use of the "rport" header field parameter as described in RFC 3581. The hosted NAT traversal for protected SIP messages is provided by applying UDP encapsulation to IPSec packets in accordance with RFC 3948.
Alternativly to the procedures defined in subclause F.2 which are employed to support the hosted NAT scenario where the security solution is based on UDP encapsulated IPSec as defined in TS 33.203, subclause F.4 provides procedures for NAT traversal for security solutions that are not defined in TS 33.203. Use of such security solutions is outside the scope of this document.
Up

F.2  Application usage of SIP  p. 832

F.2.1  UE usage of SIP  p. 832

F.2.1.1  General  p. 832

This subclause describes the UE SIP procedures for supporting hosted NAT scenarios. The description enhances the procedures specified in subclause 5.1.
The UE shall support the symmetric response routeing mechanism according to RFC 3581.

F.2.1.2  Registration and authentication  p. 832

F.2.1.2.1  General  p. 832
The text in subclause 5.1.1.1 applies without changes
F.2.1.2.1A  Parameters contained in the ISIM  p. 832
The text in subclause 5.1.1.1A applies without changes
F.2.1.2.1B  Parameters provisioned to a UE without ISIM or USIM |R8|  p. 833
The text in subclause 5.1.1.1B applies without changes.
F.2.1.2.2  Initial registration  p. 833
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 subclause 5.1.1.2.1 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: if the REGISTER request is sent without integrity protection, the Contact header field shall be set to include SIP URI(s) containing the private IP address of the UE in the hostport parameter or FQDN. If the UE supports GRUU, the UE shall include a "+sip.instance" header field parameter containing the instance ID. If the REGISTER request is integrity protected, the UE shall include the public IP address or FQDNin the hostport parameter. The UE shall only use a FQDN in a protected REGISTER request, if it is ensured that the FQDN resolves to the public IP address of the NAT. If the UE supports GRUU, the UE shall include a "+sip.instance" header field parameter containing the instance ID. 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;
d)
a Via header field according to the following rules: if the REGISTER request is sent without integrity protection, the Via header field shall be set to include the private IP address or FQDN of the UE in the sent-by field. If the REGISTER request is integrity protected, the UE shall include the public IP address or FQDN in the sent-by field. The UE shall only use a FQDN in a protected REGISTER request, if it is ensured that the FQDN resolves to the public IP address of the NAT. Unless the UE has been configured to not send keep-alives, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate support of sending keep-alives associated with, the registration, as described in RFC 6223;
If IMS AKA is used as a security mechanism, on sending a REGISTER request, as defined in subclause 5.1.1.2.1, the UE shall additionally populate the header fields as defined in subclause 5.1.1.2.2, with the exceptions of subitems c), and d) which are modified as follows:
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 protection and for encryption 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;
When a 401 (Unauthorized) response to a REGISTER is received and this response is received without integrity protection, the procedures described in subclause 5.1.1.2.1 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 of the main body of this specification;
  • If the UE is behind a NAT, the UE shall verify using the Security-Server header field that mode "UDP-enc-tun" is selected. If the verification succeeds the UE shall store the IP address contained in the "received" header field parameter as the UE public IP address. If the verification does not succeed the UE shall abort the registration. When the UE detects that it is behind a NAT, the UE may include a transport=tcp URI parameter in the Contact header when it sends a protected REGISTER.
In addition, when a 401 (Unauthorized) response to a REGISTER is received (with or without integrity protection) the UE shall behave as described in subclause F.2.1.2.5.
When the UE, that is behind a NAT, receives a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the unprotected REGISTER request, the UE shall randomly select new values for the protected server port and the protected client port, and perform new initiate registration procedure by sending an unprotected REGISTER request containing the new values in the Security-Client header field.
Up
F.2.1.2.3  Initial subscription to the registration-state event package  p. 834
The procedures described in subclause 5.1.1.3 apply with the additional procedures described in subclause F.2.1.4.1.
F.2.1.2.4  User-initiated re-registration  p. 834
The procedures described in subclause 5.1.1.4.1 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 public IP address of the UE or FQDN, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU. 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 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. If the UE has detected it is behind a NAT, the UE may include a transport=tcp URI parameter in the Contact header;
d)
a Via header field set to include the public IP address or FQDN of the UE in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continous support to send keep-alives, as described in RFC 6223;
When the UE, that is behind a NAT, receives a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the REGISTER request that does not contain a challenge response, the UE shall randomly select a new value for the protected client port, and send the REGISTER request containing the new values in the Security-Client header field.
Up
F.2.1.2.5  Authentication  p. 835
F.2.1.2.5.1  IMS AKA - general  p. 835
The procedures of subclause 5.1.1.5.1 apply with 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, 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 request (see subclause F.2.1.2.2), with the addition that the UE shall include an Authorization header field containing the private user identity and the authentication challenge response 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. 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.
Whenever 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 F.2.1.2.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF.
Up
F.2.1.2.5.2  Void
F.2.1.2.5.3  IMS AKA abnormal cases  p. 835
The text in subclause 5.1.1.5.3 applies without changes.
F.2.1.2.5.4  SIP digest - general   p. 835
Not applicable.
F.2.1.2.5.5  SIP digest - abnormal procedures   p. 835
Not applicable.
F.2.1.2.5.6  SIP digest with TLS - general   p. 835
Not applicable.
F.2.1.2.5.7  SIP digest with TLS - abnormal procedures   p. 835
Not applicable.
F.2.1.2.5.8  Abnormal procedures for all security mechanisms   p. 835
The text in subclause 5.1.1.5.8 applies without changes.
F.2.1.2.5A  Network-initiated re-authentication  p. 836
The text in subclause 5.1.1.5A applies without changes.
F.2.1.2.5B  Change of IPv6 address due to privacy |R8|  p. 836
The text in subclause 5.1.1.5B applies without changes.
F.2.1.2.6  User-initiated deregistration  p. 836
The procedures of subclause 5.1.1.6.1 apply with 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 with the exception of subitems d) and e) 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; and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE supports GRUU. 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 set to include the IP address or FQDN of the UE in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT;
Up
F.2.1.2.7  Network-initiated deregistration  p. 836
The procedures of subclause 5.1.1.7 apply with 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 F.2.1.2.2. In case of a "rejected" event attribute, the UE shall release all dialogs related to those public user identities.
Up

F.2.1.3  Subscription and notification  p. 836

The text in subclause 5.1.2 applies without changes.

F.2.1.4  Generic procedures applicable to all methods excluding the REGISTER method  p. 836

F.2.1.4.1  UE originating case  p. 836
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 replaced by the following requirements. The UE shall include:
  • a Via header field set to include the public IP address of the UE or FQDN and the protected server port in the sent-by field. The UE shall only use a FQDN, if it is ensured that the FQDN resolves to the public IP address of the NAT; and if this is a request for a new dialog, and the request includes a Contact header field, then the UE should populate the Contact header field as follows:
    1. if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field as specified in RFC 5627; or
    2. if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity to be used for this request, and the UE does indicate privacy of the P-Asserted-Identity, then insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627.
If this is a request within an existing dialog, and the request includes a Contact header field, and the contact address previously used in the dialog was a GRUU, then the UE should insert the previously used GRUU value in the Contact header field as specified in RFC 5627.
If 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 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 response 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 F.2.1.2.4.
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 F.2.1.2.3.
Up
F.2.1.4.2  UE terminating case  p. 837
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.1 are replaced by the following requirement.
If the response includes a Contact header field, and the response is not sent within an existing dialog, then the UE should populate the Contact header field as follows:
  1. if a public GRUU value ("pub-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does not indicate privacy of the P-Asserted-Identity, then insert the public GRUU ("pub-gruu" header field parameter) value in the Contact header field as specified in RFC 5627; and
  2. if a temporary GRUU value ("temp-gruu" header field parameter) has been saved associated with the public user identity from the P-Called-Party-ID header field, and the UE does indicate privacy of the P-Asserted-Identity, then the UE should insert the temporary GRUU ("temp-gruu" header field parameter) value in the Contact header field as specified in RFC 5627.
If 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 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 F.2.1.2.
Up

F.2.2  P-CSCF usage of SIP  p. 838

F.2.2.1  Introduction  p. 838

This subclause describes the SIP procedures for supporting hosted NAT scenarios.
The description enhances the procedures specified in subclause 5.2.
The P-CSCF shall support the symmetric response routeing mechanism according to RFC 3581.
Up

F.2.2.2  Registration  p. 838

The procedures described in subclause 5.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 of subclause 5.2.2.1.
If IMS AKA is the security mechanism, when the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall perform the procedures of subclause 5.2.2.2 with the following exception to items 2) and 3):
2)
in case the REGISTER request was received without integrity protection, then:
  1. check the existence of the Security-Client header field. If the Security-Client header field is not present, 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.
    • 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;
      • otherwise continue with procedures as of subclause 5.2.2.
  2. if the host portion of the sent-by field in the topmost Via header field contains a FQDN, or if it contains an IP address that differs from the source address of the IP packet, the P-CSCF shall:
    • add a "received" header field parameter in accordance with the procedure defined in RFC 3581. If the "rport" header field parameter is included in the Via header field, the P-CSCF shall also set the value of the "rport" header field parameter to the source port of the requestin accordance with the procedure defined in RFC 3581; and
    • check that no any previously registered UE has either the same public IP address (allocated by the NAT and indicated in the Via header field) and the protected server port (specified in the Security-Client header field) or the same public IP address and the protected client port (specified in the Security-Client header field). If there is such UE, the P-CSCF shall return a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the unprotected REGISTER request. Otherwise, the P-CSCF shall forward the REGISTER request.
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 the security association is a temporary one, the P-CSCF shall:
    • in case the host 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, 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. 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;
  2. if the security association the REGISTER request was received on, is an already established one, then the P-CSCF shall:
    • remove the Security-Verify header field if it is present;
    • check if the Security-Client header field containing new parameter values is present, and:
    • if this header field or any required parameter is missing, then the P-CSCF shall return a suitable 4xx response.
    • if this header field and the required parameters are present, then the P-CSCF shall check that no any previously registered UE has the same public IP address and the protected client port (specified in the Security-Client header field). If there is such UE, the P-CSCF shall return a 400 (Bad Request) response with 301 Warning header field indicating "incompatible network address format" to the REGISTER request. Otherwise, the P-CSCF shall remove and store the Security-Client header field before forwarding the request to the S-CSCF;
When the P-CSCF receives a 401 (Unauthorized) response to an unprotected REGISTER request:
  1. if this response contains a "received" header field parameter in the Via header field associated with the UE;
  2. if the request associated with the response was received:
    1. using UDP and this response contains a "rport" header field parameter in the Via header field associated with the UE; or
    2. using TCP; and
  3. 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. 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 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. in case UDP is used as transport protocol the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and to the port indicated in the "rport" header field parameter of the Via header field associated with the UE. In case UDP is used as transport protocol, the P-CSCF shall use the IP address and the port on which the REGISTER request was received as source IP address and the source port when sending the response back to the UE.
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 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.
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.
Up

F.2.3  S-CSCF usage of SIP  p. 840

F.2.3.1  S-CSCF usage of SIP  p. 840

F.2.3.1.1  Protected REGISTER with IMS AKA as a security mechanism |R8|  p. 840
The procedures at the S-CSCF described in subclause 5.4.1.2.2 apply.
Up

F.3  Void

F.4  P-CSCF usage of SIP in case UDP encapsulated IPsec is not employed  p. 841

F.4.1  Introduction  p. 841

The subclause F.4 describes the SIP procedures for supporting hosted NAT scenarios in case UDP encapsulated IPsec is not employed. In these scenarios the procedures for NAT traversal must take into account that all SIP requests and responses are not protected by an IPsec security association. This subclause also assumes that the UE transmits the SIP messages from the same IP address and port on which the UE expects to receive SIP messages.
Up

F.4.2  Registration  p. 841

The procedures described in subclause 5.2.2 apply with the additional procedures described in the present clause.
When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall add the "received" header field parameter to the Via header field set to the source IP address of the packet header in accordance with the procedure defined in RFC 3261 and RFC 3581. If the "rport" header field parameter is included in the Via header field, the P-CSCF shall also set the value of the "rport" header field parameter to the source port of the request, in accordance with the procedure defined in RFC 3581.
When the P-CSCF detects that the UE is behind a NAT:
  • if the UE has indicated in the received REGISTER request support of the keep-alive mechanism defined in SIP outbound (RFC 5626) according to RFC 6223, the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and
  • if the UE has not indicated in the received REGISTER request support of the keep-alive mechanism defined in SIP outbound (RFC 5626) according to RFC 6223:
    1. if a P-CSCF registration timer is running, the P-CSCF should not forward the REGISTER request if received half of the time before expiry of the S-CSCF registration timer, unless the request is intended to update the UE's capabilities according to RFC 3840 or to modify the ICSI values or IARI values that the UE intends to use in the g.ims.app-ref feature tag. If the P-CSCF decides to not forward the REGISTER request, the P-CSCF shall build a 200 (OK) response based on the contents of the 200 (OK) response to the previous REGISTER request and send this response to the UE. If the P-CSCF decides to forward the REGISTER request, the P-CSCF shall set the registration expiration interval to the registration expiration interval value indicated in the received 200 (OK) response to the previous REGISTER request; and
    2. when the P-CSCF receives a 200 (OK) response to the REGISTER request, the P-CSCF shall modify the value of the Expires header field and/or Expires parameter in the Contact header according to the transport protocol. In order to minimize the number of REGISTER requests to the S-CSCF, the P-CSCF may also start a P-CSCF registration timer with a value of 600 seconds if the value received from the S-CSCF was for greater than 1200 seconds, or to half of the time otherwise.
If, upon receiving a REGISTER request from an unregistered user and the P-CSCF discovers that the UE is behind a NAT, the P-CSCF performs the following actions on the Contact header field depending on its content:
  • if the Contact header field contains a contact address in the form of an IP address (NOTE), the P-CSCF shall save (for the duration of the registration) this IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) and bind them to the source IP address (i.e. the public IP address of the NAT) and the source port number (i.e. the port number of the NAT) of the IP packet that contained the REGISTER request and forward the REGISTER request;
  • if the Contact header field contains more than one contact addresses in the form of an IP address, the P-CSCF shall apply the above procedure to one of those contact addresses by choosing the one with the highest qvalue parameter) and delete any other contact addresses containing an IP address. If the P-CSCF was unable to choose a contact address based on the qvalue, the P-CSCF shall choose one based on local policy and delete any other contact addresses containing an IP address.
When the P-CSCF received a response to the above request, the P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3581. In case UDP is used, the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and to the port indicated in the "rport" header field parameter of the Via header field in the response. If the REGISTER request received from the UE was received over a TCP connection, the P-CSCF shall send the response to the UE over the same TCP connection over which the request was received. The P-CSCF shall transmit the IP packet (containing the response) from the same IP address and port on which the REGISTER request was received.
Up

F.4.3  General treatment for all dialogs and standalone transactions excluding the REGISTER method  p. 842

F.4.3.1  Introduction  p. 842

The procedures described in subclause 5.2.6 apply with the additional procedures described in subclause F.4.3.

F.4.3.2  Request initiated by the UE  p. 842

When the P-CSCF receives, from the UE that is behind a NAT, an initial request for a dialog or a request for a standalone transaction, the P-CSCF shall:
a)
if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field to the source port of the received IP packet that contained the request;
aa)
insert the "received" header field parameter in the Via header field containing the source IP address of the received IP packet (that contained the request), as defined in RFC 3581;
b)
if the request is a dialog-forming request that was received over UDP, bind the source IP address (i.e. the public IP address of the NAT) and associated source port number (i.e. the port number of the NAT) of the received IP packet (that contained the initial dialog-forming request) to:
  • the IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) contained in the Contact header field of the received dialog-forming request, if the Contact header field contained an IP address and associated port number, and save the binding; or
  • the saved IP address (i.e. the private IP address of the UE) and associated port number (i.e. the private port of the UE) contained in the Contact header field of the REGISTER request, if the Contact header field of the received dialog-forming request contained a GRUU, and save the binding; and
c)
if the dialog-forming request was received over TCP connection, keep this TCP connection up during the entire duration of the dialog;
before forwarding the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
When the P-CSCF receives a response to the above request, the P-CSCF shall forward the response to the UE using the mechanisms described in RFC 3581. In case UDP is used, the P-CSCF shall send the response to the IP address indicated in the "received" header field parameter and to the port indicated in the "rport" header field parameter of the Via header field of the response. If the dialog-forming request received from the UE was received over the TCP connection, the P-CSCF shall send the response to the UE over the same TCP connection over which the dialog-forming request was received. The P-CSCF shall transmit the IP packet (containing the response) from the same IP address and port on which the initial dialog-forming request was received.
For all subsequent requests belonging to the dialog, received from the UE, the P-CSCF shall:
  • insert the "received" header field parameter in the Via header field as described in RFC 3261;
  • if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field as defined in RFC 3581; and
  • forward the request as described in RFC 3261.
For all subsequent responses belonging to the dialog, destined for the UE, the P-CSCF shall forward the responses using the "received" header field parameter and if UDP is used, set the value of the "rport" header field parameter in the Via header field of the response as defined in RFC 3581.
For all subsequent requests belonging to the dialog and destined for the UE (that contains the private IP address and associated private port number in the Request-URI), the P-CSCF shall send the requests to the UE either:
  • over the TCP connection that was established when the initial INVITE request was received; or
  • use UDP. When sending the request using UDP, the P-CSCF shall insert the request in an IP packet, and send the IP packet to the saved IP address (i.e. the public IP address of the NAT) and associated port number (i.e. the port number of the NAT). The P-CSCF shall transmit the IP packet (containing the request) from the same IP address and port on which the REGISTER request was received.
Up

F.4.3.3  Request terminated by the UE  p. 843

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction destined for the UE (it contains the private IP address and associated private port number in the Request-URI), the P-CSCF shall send the requests to the UE either:
  • over the TCP connection for the related registration or registration flow (if the multiple registrations mechanism is used), if available (e.g. TCP connection was established during the registration procedure); or
  • use UDP. When sending the request using UDP, the P-CSCF shall send the request to the saved IP address (i.e. the public IP address of the NAT) and associated port number (i.e. the port number of the NAT) for the related registration or registration flow (if the multiple registrations mechanism is used) that is bound to the private IP address and associated private port number indicated in the Request-URI and saved during the registration procedure. The P-CSCF shall transmit the IP packet (containing the request) from the same IP address and port on which the REGISTER request was received.
For all subsequent requests belonging to the dialog that are received from the UE, the P-CSCF shall:
  • insert the "received" header field parameter in the Via header field as defined in RFC 3261;
  • if the "rport" header field parameter is included in the Via header field, set the value of the "rport" header field parameter in the Via header field as defined in RFC 3581; and
  • forward the request as described in RFC 3261.
For all subsequent responses belonging to the dialog, destined or the UE, the P-CSCF shall forward the responses using the "received" header field parameter and if UDP is used, set the value of the "rport" header field parameter in the Via header field of the response as defined in RFC 3581.
For all subsequent requests belonging to the dialog and destined for the UE (that contains the private IP address and associated private port number in the Request-URI), the P-CSCF shall send the requests to the UE either:
  • over the TCP connection, if available; or
  • use UDP. When sending the request using UDP, the P-CSCF shall insert the request in an IP packet, and send the IP packet to the saved IP address (i.e. the public IP address of the NAT) and associated port number (i.e. the port number of the NAT). The P-CSCF shall transmit the IP packet (containing the request) from the same IP address and port on which the REGISTER request was received.
Up

F.5  NAT traversal for media flows |R8|  p. 844

To allow the IMS access gateway to perform address latching, for a given UDP-based media stream, the UE shall use the same port number for sending and receiving packets.
To allow early media flows, the UE shall send keepalive messages for each UDP-based media stream as soon as an SDP offer or answer is received in order to allow the IMS access gateway to perform address latching before the call is established.
To keep NAT bindings and firewall pinholes open for the UDP-based media streams, and enable the IMS access gateway to perform address latching, the UE shall send keepalive messages for each media stream as defined in subclause K.5.2.1.
Up

G  Void

Up   Top   ToC