Hello, I reviewed http://tools.ietf.org/id/draft-gundavelli-ipsecme-3gpp-ims-options-02.txt and found the following issues:
ISSUE 1: the draft states: ------ These attributes can be used for carrying the IPv4 and IPv6 address of the Proxy-Call Control and Service function (P-CSCF). ------ In 3GPP, P-CSCF abbreviation stands for "Proxy-Call Session Control Function". PROPOSAL 1: state: ------ These attributes can be used for carrying the IPv4 address and IPv6 address of the Proxy-Call Session Control function (P-CSCF). ------ ISSUE 2: the draft states: ------ When an IPSec gateway delivers these attributes to an IPsec client, it can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the home network. ------ The P-CSCF does not necessarily need to be located in the home network. In roaming situations, the P-CSCF can also be in visited network. Example: User has a contract with an European operator. The user with its user equipment (UE) is in Japan and uses network of a Japanese operator. In such use case, the ePDG entity, the PGW entity and P-CSCF can all be in visited network (i.e. Japanese operator network). PROPOSAL 2: state: ------ When an IPSec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network. ------ ISSUE 3: the draft states: ------ The Third Generation Partnership Project (3GPP) S2b reference point [TS23402], specified by the 3GPP system architecture defines a mechanism for allowing a mobile node (MN) attached in an untrusted non-3GPP IP Access Network to securely connect to the 3GPP home network and access IP services. ------ When roaming, the UE can access IP services in the 3GPP home network or 3GPP visited network. ePDG can be in visited or home network - see http://www.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c50.zip section 4.5.4. If so, P-GW and P-CSCF can also be in the visited network. PROPOSAL 3: state: ------ The Third Generation Partnership Project (3GPP) S2b reference point [TS23402], specified by the 3GPP system architecture defines a mechanism for allowing a mobile node (MN) attached in an untrusted non-3GPP IP Access Network to securely connect to a 3GPP network and access IP services. ------ ISSUE 4: the draft states: ------ A mobile node in this scenario may potentially need to access the IP Multimedia Subsystem (IMS) services in the home network. ------ P-CSCF can also be in visited network. PROPOSAL 4: state: ------ A mobile node in this scenario may potentially need to access the IP Multimedia Subsystem (IMS) services in the 3GPP network. ------ ISSUE 5: the draft states: ------ Proxy-Call Session Control Function (P-CSCF) The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia Subsystem) domain and serves as the outbound proxy server for the mobile node. The mobile node attaches to the P-CSCF prior to performing IMS registrations and initiating SIP sessions. ------ Problems: 1) 3GPP IMS is not a domain. 2) The mobile node does NOT attach to P-CSCF prior to performing the IMS registration. Instead, the registration with IMS is the request for "attachment" to IMS. PROPOSAL 5: state: ------ Proxy-Call Session Control Function (P-CSCF) The P-CSCF is the entry point to the 3GPP IMS (IP Multimedia Subsystem) and serves as the SIP outbound proxy for the mobile node. The mobile node performs SIP registration to 3GPP IMS and initiates SIP sessions via a P-CSCF. ------ ISSUE 6: the draft states: ------ Multiple P-CSCF servers MAY be requested by including a single instance of an empty P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field. The responder MAY respond with zero or more P-CSCF_IP4_ADDRESS attributes, and there is no implied order in the response. ------ IMO, the 1st sentence above is misleading as it suggests that the mobile node has a choise to request one P-CSCF IPv4 address or to request multiple P-CSCF IPv4 addresses. However, in my reading of the rest of the draft, the mobile node has just one choise - request P-CSCF IPv4 addresses and receive zero, one or several P-CSCF IPv4 addresses. PROPOSAL 6: state: ------ If an instance of an empty P-CSCF_IP4_ADDRESS attribute with zero-length IPv4 Address field is included by mobile node, the responder MAY respond with zero, one or more P-CSCF_IP4_ADDRESS attributes. If several P-CSCF_IP4_ADDRESS attributes are provided in one IKEv2 message, there is no implied order among the P-CSCF_IP4_ADDRESS attributes. ------ ISSUE 7: the draft states: ------ Multiple P-CSCF servers MAY be requested by including a single instance of an empty P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field. The responder MAY respond with zero or more P-CSCF_IP6_ADDRESS attributes, and there is no implied order in the response. ------ IMO, the 1st sentence above is misleading as it suggests that the mobile node has a choise to request one P-CSCF IPv6 address or to request multiple P-CSCF IPv6 addresses. However, in my reading of the rest of the draft, the mobile node has just one choise - request P-CSCF IPv6 addresses and receive zero, one or several P-CSCF IPv6 addresses. PROPOSAL 7: state: ------ If an instance of an empty P-CSCF_IP6_ADDRESS attribute with zero-length IPv6 Address field is included by mobile node, the responder MAY respond with zero, one or more P-CSCF_IP6_ADDRESS attributes. If several P-CSCF_IP6_ADDRESS attributes are provided in one IKEv2 message, there is no implied order among the P-CSCF_IP6_ADDRESS attributes. ------ Kind regards Ivo Sedlacek Ericsson Mobile +420 608 234 709 [email protected] www.ericsson.com This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
