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

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Wed, 10 September 2014 15:42 UTC

Return-Path: <sgundave@cisco.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 B7ACA1A8734 for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 08:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level:
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 P8R-ELZK6S-x for <ipsec@ietfa.amsl.com>; Wed, 10 Sep 2014 08:42:30 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262481A872F for <ipsec@ietf.org>; Wed, 10 Sep 2014 08:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24492; q=dns/txt; s=iport; t=1410363750; x=1411573350; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=a03E+yCTYoD3dTEU/5bx3eDGujgK51GUVfIzG9QX8P0=; b=CjBMKd9+8cxp+zIPzkXf41s2RmMdtGjKWlPUdE1C7+GCRKyNjR7e5g6Y 7h3+1n7QvKt3deXQEJliJZ49a6Y6EVGECWIfglob8VhhHWeTT1MfmIyOz 9qDgxQ082kHxqlLvWKKtE2iegFCk2ETgj3rDDhLpilmROg2J2zrOS2lqW 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlUFANlwEFStJV2S/2dsb2JhbABZgkdGU1cEyFaBaodKAYEQFniEBAIESSgIEgEIEiYHORQDDgIEAQ0FiEINvmMBF45rEQFNAwYBCYRDBY8sghWEMII8hEaBX40KhkWDYWwBAYENOYEHAQEB
X-IronPort-AV: E=Sophos; i="5.04,499,1406592000"; d="scan'208,217"; a="76691793"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 10 Sep 2014 15:42:27 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8AFgR5s030837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 15:42:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 10:42:27 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: Review of draft-gundavelli-ipsecme-3gpp-ims-options-02
Thread-Index: AQHPzQ3SKMQYWriGR/e+ppRj0kUPVQ==
Date: Wed, 10 Sep 2014 15:42:26 +0000
Message-ID: <D035BCAE.162A5C%sgundave@cisco.com>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061011272E731@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.210]
Content-Type: multipart/alternative; boundary="_000_D035BCAE162A5Csgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-AfT8cxBJSyoDIzR56dt9bEaQr4
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: Wed, 10 Sep 2014 15:42:32 -0000

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

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer