IETF Logo Mail Archive

Re: [Hipsec] TRANSPORT_FORMAT_LIST issues in 5201-bis and 5202-bis

René Hummen <Rene.Hummen@comsys.rwth-aachen.de> Thu, 27 June 2013 09:20 UTC

Return-Path: <Rene.Hummen@comsys.rwth-aachen.de>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BC621F9C7F for <hipsec@ietfa.amsl.com>; Thu, 27 Jun 2013 02:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.948
X-Spam-Level:
X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 wZtEAZM2RURa for <hipsec@ietfa.amsl.com>; Thu, 27 Jun 2013 02:19:47 -0700 (PDT)
Received: from mx-out-2.rwth-aachen.de (mx-out-2.rwth-aachen.de [134.130.5.187]) by ietfa.amsl.com (Postfix) with ESMTP id B107121F9C72 for <hipsec@ietf.org>; Thu, 27 Jun 2013 02:19:45 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.87,950,1363129200"; d="scan'208,217"; a="139521474"
Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by mx-2.rz.rwth-aachen.de with ESMTP; 27 Jun 2013 11:19:45 +0200
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_iGLVN9XrNtBUYargdACJpQ)"
Received: from i4-mbp.informatik.rwth-aachen.de ([unknown] [137.226.12.102]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0MP100CRGOKWJ380@relay-auth-1.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Thu, 27 Jun 2013 11:19:44 +0200 (CEST)
From: René Hummen <Rene.Hummen@comsys.rwth-aachen.de>
In-reply-to: <758141CC3D829043A8C3164DD3D593EA2ED6C951B3@XCH-NW-16V.nw.nos.boeing.com>
Date: Thu, 27 Jun 2013 11:19:47 +0200
Message-id: <5FBDFE72-9531-4E3F-AD70-D03E09FB9B57@comsys.rwth-aachen.de>
References: <F42340E7-9106-4EC7-8C03-D93B311955CB@comsys.rwth-aachen.de> <758141CC3D829043A8C3164DD3D593EA2ED6C951B2@XCH-NW-16V.nw.nos.boeing.com> <758141CC3D829043A8C3164DD3D593EA2ED6C951B3@XCH-NW-16V.nw.nos.boeing.com>
To: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
X-Mailer: Apple Mail (2.1508)
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] TRANSPORT_FORMAT_LIST issues in 5201-bis and 5202-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 09:20:06 -0000

On 27.06.2013, at 07:45, "Henderson, Thomas R" <thomas.r.henderson@boeing.com> wrote:
>> Furthermore, I suggest to move the ESP_TRANSFORM negotiation to the I2
>> and R2 in order to complete the transport format type negotiation
>> before starting the ESP transform negotiation. As I see it, this should
>> not negatively impact ESP SA setup as the KEYMAT index in the ESP_INFO
>> parameter is independent from the chosen ESP Suite ID. Or did I make a
>> mistake here?
>> 
> 
> Here, I think the impact may be that it is not aligned with other negotiations in which the responder provides the list for the initiator to choose from.  By delaying it as you suggest, the initiator will be sending the list of acceptable transforms and the responder choosing.

Ok, but the Initiator already proposes the DH_GROUP_LIST in HIPv2.

> As is currently specified, the inclusion in R1 also adds clarity to the TRANSPORT_FORMAT_LIST in the sense that the responders clarifies to the initiator, e.g. "I accept ESP, and by ESP, I mean the suites defined in this ESP_TRANSFORM list", and the initiator can decide to proceed or not based on that information.

That's actually a good point.

> The downside to the current text seems to be that some bytes may be wasted in starting the transform-specific negotiations for possibly unselected transforms.  I don't know how much this would occur or be a problem in practice. 


We could argue that resource-constrained devices will probably restrict support to a single transform for the sake of minimizing ROM overhead and that the additional parameter adds negligible overhead in unconstrained scenarios. With this line of argumentation, we can leave the negotiation in 5202-bis as it is today. Other opinions?

BR
René


--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21429
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

v2.23.0 | Report a Bug | By Email