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
- [IPsec] Some comments to the draft-gundavelli-ips… Tero Kivinen
- Re: [IPsec] Some comments to the draft-gundavelli… Sri Gundavelli (sgundave)
- Re: [IPsec] Some comments to the draft-gundavelli… Tero Kivinen
- Re: [IPsec] Some comments to the draft-gundavelli… Sri Gundavelli (sgundave)