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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 995ED11E80A5 for <>; Mon, 22 Apr 2013 07:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WJYn9YaJO82P for <>; Mon, 22 Apr 2013 07:26:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 658D311E80A2 for <>; Mon, 22 Apr 2013 07:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="4.87,526,1363132800"; d="scan'208";a="201607316"
Received: from ([]) by with ESMTP; 22 Apr 2013 14:26:06 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 09:26:05 -0500
From: "Sri Gundavelli (sgundave)" <>
To: Tero Kivinen <>
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: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "Aeneas Dodd-Noble \(noblea\)" <>, "" <>, "" <>
Subject: Re: [IPsec] Some comments to the draft-gundavelli-ipsecme-3gpp-ims-options-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Apr 2013 14:26:10 -0000

Hi Tero,

On 4/22/13 5:29 AM, "Tero Kivinen" <> 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" <> 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,
>> the server can populate it. So, the client sends a request with a
>> NULL/ value, and the server can include the Attribute with a
>> 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
>> with a value of, 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.


>> >----------------------------------------------------------------------
>> >   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
>> >      connection existed with this address and the requestor would like
>> >      to reuse that address.  With IPv6, a requestor MAY supply the
>> >      order address octets it wants to use.  Multiple internal
>> >      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
>> 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.