Re: [IPsec] Review of draft-gundavelli-ipsecme-3gpp-ims-options-02

Ivo Sedlacek <ivo.sedlacek@ericsson.com> Thu, 11 September 2014 07:40 UTC

Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EDF1A06C9 for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDgZgSy7j_ld for <ipsec@ietfa.amsl.com>; Thu, 11 Sep 2014 00:40:14 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2666C1A0601 for <ipsec@ietf.org>; Thu, 11 Sep 2014 00:40:12 -0700 (PDT)
X-AuditID: c1b4fb25-f791c6d00000617b-7d-541151db11c9
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.53.24955.BD151145; Thu, 11 Sep 2014 09:40:11 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.77]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Thu, 11 Sep 2014 09:40:10 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
Thread-Index: AQHPzQ3SKMQYWriGR/e+ppRj0kUPVZv7jLDA
Date: Thu, 11 Sep 2014 07:40:09 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011272F963@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061011272E731@ESESSMB301.ericsson.se> <D035BCAE.162A5C%sgundave@cisco.com>
In-Reply-To: <D035BCAE.162A5C%sgundave@cisco.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011272F963ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM+Jvje7tQMEQg3NfxS0WzVvAZLF/yws2 i/3rGpgsug5OZ7M4+GcbmwOrx6z7Z9k8pvzeyOqxc9Zddo8lS34yBbBEcdmkpOZklqUW6dsl cGVMmH+duWDHduaKE/9nsTUwfu5m7mLk5JAQMJHYuvc4lC0mceHeerYuRi4OIYGjjBKdayYw QziLGSUO329gBKliE9CTmLjlCCuILSIQKTFr3QWwDmaBfkaJK/ums4AkhAWcJeb/Wc0MUeQi MbnzChuEbSRx9tZ3sDiLgKpE98alQEM5OHgFfCVmzbMACQsJlEjsu/YVbBengKHE2a2zwFoZ BWQlrv7pBYszC4hL3HoynwniagGJJXvOQ30gKvHy8T9WkJESAooSy/vlIMrzJfo6rrKD2LwC ghInZz5hmcAoOgvJpFlIymYhKYOI60k8OzULytaWWLbwNTOErStx6eE6VmTxBYzsqxhFi1OL k3LTjYz1Uosyk4uL8/P08lJLNjECo/Tglt+qOxgvv3E8xCjAwajEw5tgJRgixJpYVlyZe4hR moNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYVZZNlb6mKDFTT6eG7dvXsweY NxxgVt/0z/dG8k+HmJm5ZeV9k2bfO7DowXa3O0c7tx5suSolsMIk0b2h+G137cp01xnSbKH3 p3qk6L655vgmNjnZQavr8LYbv8tzZs857qcdVLGnX2sdp1OtwlPWeQ3t5wx2ad3cI3/3j+ai ro9LdLoU5nwPVGIpzkg01GIuKk4EAEYAUBuzAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/uW69c9kM3_5stP6S6nTaOYFeOVc
Cc: "Aeneas Dodd-Noble (noblea)" <noblea@cisco.com>, Jouni Korhonen <jouni.nospam@gmail.com>, "baboescu@broadcom.com" <baboescu@broadcom.com>
Subject: Re: [IPsec] Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 07:40:19 -0000

Hello,

I checked draft-gundavelli-ipsecme-3gpp-ims-options-03.

My comments are resolved in draft-gundavelli-ipsecme-3gpp-ims-options-03

Thank you for taking my comments into account.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: 10. září 2014 17:42
To: Ivo Sedlacek; ipsec@ietf.org
Cc: Jouni Korhonen; Aeneas Dodd-Noble (noblea); baboescu@broadcom.com
Subject: Re: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02

Hi Ivo,

Thanks for your response. Please see inline.


On 9/9/14 4:09 AM, "Ivo Sedlacek" <ivo.sedlacek@ericsson.com<mailto:ivo.sedlacek@ericsson.com>> wrote:

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).
------


Ok




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

The "home" network terminology was not truly intended to reflect the 3GPP roaming architecture. Its just to say the configuration comes from the PGW/LMA.

But, agree with the change.



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


The "home" network terminology was not truly intended to reflect the 3GPP roaming architecture. Its just to say the configuration comes from the PGW/LMA.

But, agree with the change.




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



Ok




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


Thanks. That was a typo. It should have said, "the mobile node attaches to the 3GPP network ...".

Agree with the text.




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


The proposed text is very clear. Thank you




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

The proposed text is very clear. Thank you



Thanks for a detailed review.

Regards
Sri




Kind regards

Ivo Sedlacek
Ericsson
Mobile +420 608 234 709
ivo.sedlacek@ericsson.com<mailto:ivo.sedlacek@ericsson.com>
www.ericsson.com<http://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<http://www.ericsson.com/email_disclaimer>