Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Mon, 22 April 2013 14:26 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995ED11E80A5 for <ipsec@ietfa.amsl.com>; Mon, 22 Apr 2013 07:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJYn9YaJO82P for <ipsec@ietfa.amsl.com>; Mon, 22 Apr 2013 07:26:08 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 658D311E80A2 for <ipsec@ietf.org>; Mon, 22 Apr 2013 07:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5826; q=dns/txt; s=iport; t=1366640766; x=1367850366; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=21s82wrFapy8/Zu08C4GRuRdAaD/4cc6NSZylILFpxk=; b=HY5SwYsEECUlJJHICg4pXrFFTgEMwOeTptyNksRT1gNSOgGV+2o03lhG 0gjrI8lPXVU86fhvpweprHMHqRajXw1HHxSPe4mnT578mtTJMRFPVHs6d I2xLjBUBfRswFJMHame11AZmDkjbyU634+8/cRYhKA8iGVuYxIDXwFass g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFAMFHdVGtJXG8/2dsb2JhbABPgwbBOIEGFnSCHwEBAQQ6PxIBCBgKFEIlAgQOBQiIDLsYjw4xB4JmYQOTRpRpgwyCKA
X-IronPort-AV: E=Sophos;i="4.87,526,1363132800"; d="scan'208";a="201607316"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 22 Apr 2013 14:26:06 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3MEQ5p1026783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 14:26:05 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 09:26:05 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>
Thread-Topic: Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt
Thread-Index: AQHOPBbfkK3N7LSI7ECyznXpomQb85jhBvIAgAF+4wD//6sXAA==
Date: Mon, 22 Apr 2013 14:26:04 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA810246BB5@xmb-aln-x03.cisco.com>
In-Reply-To: <20853.11588.93501.817653@fireball.kivinen.iki.fi>
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.214]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3AB5253AA0A0C147BCBB080411C189EA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Aeneas Dodd-Noble (noblea)" <noblea@cisco.com>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>, "baboescu@broadcom.com" <baboescu@broadcom.com>
Subject: Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 22 Apr 2013 14:26:10 -0000

Hi Tero,



On 4/22/13 5:29 AM, "Tero Kivinen" <kivinen@iki.fi> wrote:

>Sri Gundavelli (sgundave) writes:
>> Hi Tero,
>> 
>> Thanks a lot for the review comments. This is very helpful.
>> 
>> Please see inline.
>> 
>> 
>> On 4/18/13 2:26 AM, "Tero Kivinen" <kivinen@iki.fi> wrote:
>> 
>> >In section 3 and 4, there is text saying:
>> >
>> >----------------------------------------------------------------------
>> >...
>> >   Length (2 octets)
>> >      Length of the value field in octets.  In this case, its 4.
>> >...
>> >   Length (2 octets)
>> >      Length of the value field in octets.  In this case, its 16.
>> >...
>> >----------------------------------------------------------------------
>> >
>> >But the length of the configuration attribute value can also be 0 for
>> >the requests. At least in general case, I do not know whether this
>> >P-CSCF_IP{4,6}_ADDRESS option is supposed to be normal configurable
>> >option or something else. In normal case the client either sends empty
>> >request, and server fills the value in, or the client sends request
>> >telling the preferred value, and server either replies with that or
>> >something else.
>> 
>> The goal is to allow the client to request for the configuration value,
>>so
>> the server can populate it. So, the client sends a request with a
>> NULL/0.0.0.0 value, and the server can include the Attribute with a
>>proper
>> value in the response message.
>
>In normal IKEv2 case the configuration payload in that case will be
>empty, see RFC5996 section 3.15.1:
>
>----------------------------------------------------------------------
>3.15.1.  Configuration Attributes
>...
>   The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
>   information from its peer.  If an attribute in the CFG_REQUEST
>   Configuration payload is not zero-length, it is taken as a suggestion
>   for that attribute.  The CFG_REPLY Configuration payload MAY return
>   that value, or a new one.  It MAY also add new attributes and not
>   include some requested ones.  Unrecognized or unsupported attributes
>   MUST be ignored in both requests and responses.
>...
>----------------------------------------------------------------------
>
>It would be better to use same mechanisms for all IKEv2 configuration
>attributes, and not make special cases for some attributes.


OK. This is fine. I will make the change.



>
>> >The draft also says:
>> >
>> >----------------------------------------------------------------------
>> >   Multiple instances of this Attribute with different values can be
>> >   present in the configuration payload and there is no implied
>> >   preferrential order.
>> >----------------------------------------------------------------------
>> >
>> >In RFC5996 we have text which says that for INTERNAL_IP{4,6}_ADDRESS
>> >the multi-valued return values only work in a way, that client sends
>> >as many entries in the request as it is willing to get back in the
>> >reply, and server can only return as many (or fewer) items there was
>> >in the request. This is to allow client to decide whether it wants to
>> >support multi-valued addresses. Do you want to do similar thing here,
>> >or is it assumed that all implementations do allow multiple values for
>> >this attribute? The text from RFC5996 says as follows:
>> 
>> 
>> The client should be able to include a single a instance of the
>>Attribute
>> with a value of 0.0.0.0, but the server should be able to offer one or
>> more instances of the Attribute.
>> 
>> In this case, there is no real requirement for the client to indicate
>> capability for multiple instances. We can safely assume the client can
>> handle one or more values.
>
>Ok, if client is known to be able to handle multiple values, then
>there is no need to indicate that by sending multiple requests.

Ack.

>
>> >----------------------------------------------------------------------
>> >   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
>> >      internal network, sometimes called a red node address or private
>> >      address, and it MAY be a private address on the Internet.  In a
>> >      request message, the address specified is a requested address (or
>> >      a zero-length address if no specific address is requested).  If a
>> >      specific address is requested, it likely indicates that a
>>previous
>> >      connection existed with this address and the requestor would like
>> >      to reuse that address.  With IPv6, a requestor MAY supply the
>>low-
>> >      order address octets it wants to use.  Multiple internal
>>addresses
>> >      MAY be requested by requesting multiple internal address
>> >      attributes.  The responder MAY only send up to the number of
>> >      addresses requested.
>> >----------------------------------------------------------------------
>> >
>> >This also points out how the request can either be empty or have some
>> >previously used value in. Do you want to do similar thing here?
>> 
>> The request should be empty. I don't believe ePDG is sending specific
>> hints over S2b interface and so we are bound by that interface
>>definition.
>> I will check the spec to be sure.
>
>In configuration payload format the empty attribute means that the
>attribute length is 0, and the value is omitted, in your case the
>attribute length was not allowed to be 0, so the attribute cannot be
>empty, but I think it would be better to change it so it can have
>length "0 or 4 octects" and "0 or 16 octects", just like all other
>IKEv2 Configuration Attributes.
>--


Sure. I will make the change to allow empty container.



Regards
Sri



> 
>kivinen@iki.fi