[Hipsec] HIP transforms

Tobias Heer <heer@cs.rwth-aachen.de> Sat, 12 February 2011 16:47 UTC

Return-Path: <heer@informatik.rwth-aachen.de>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 961883A69EF for <hipsec@core3.amsl.com>; Sat, 12 Feb 2011 08:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id H70-P8uEukKM for <hipsec@core3.amsl.com>; Sat, 12 Feb 2011 08:47:28 -0800 (PST)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE []) by core3.amsl.com (Postfix) with ESMTP id 20ACB3A69C9 for <hipsec@ietf.org>; Sat, 12 Feb 2011 08:47:27 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-1.rz.rwth-aachen.de ([]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LGI000SPJZKZJ40@mta-2.ms.rz.RWTH-Aachen.de> for hipsec@ietf.org; Sat, 12 Feb 2011 17:47:44 +0100 (CET)
X-IronPort-AV: E=Sophos;i="4.60,462,1291590000"; d="scan'208";a="93881295"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sat, 12 Feb 2011 17:47:45 +0100
Received: from [] ([unknown] []) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LGI00H43JZKJU00@relay-auth-2.ms.rz.rwth-aachen.de> for hipsec@ietf.org; Sat, 12 Feb 2011 17:47:44 +0100 (CET)
From: Tobias Heer <heer@cs.rwth-aachen.de>
Date: Sat, 12 Feb 2011 17:47:42 +0100
Message-id: <3B655520-4A45-4B06-8616-76B39E66976B@cs.rwth-aachen.de>
To: hipsec@ietf.org
X-Mailer: Apple Mail (2.1082)
Cc: Jan Melen <jan.melen@nomadiclab.com>, Ari Keränen <ari.keranen@ericsson.com>
Subject: [Hipsec] HIP transforms
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Sat, 12 Feb 2011 16:47:29 -0000

Hi everyone,

this came up in Miika's and Ari's review of 5201-bis. The cited text comes from
rfc5201 - This also affects rfc5202.

> 5.2.1.  TLV Format
>  The type-field value also describes the order of these
>  fields in the packet, except for type values from 2048 to 4095 which
>  are reserved for new transport forms.
   Parameters using type values from 2048 up to 4095 are transport
   formats.  Currently, one transport format is defined: the ESP
   transport format [I-D.ietf-hip-rfc5202-bis].  The order of these
   parameters does not follow the order of their type value, but they
   are put in the packet in order of preference.  The first of the
   transport formats it the most preferred, and so on.


> Ari: This is a bit strange exception. I wonder if it would make sense to make this consistent with the other ordered lists, i.e., have one parameter that lists the supported transport formats and then, depending on which format was chosen, the corresponding parameter(s) from this range are used (and others ignored).

As Ari correctly stated, we have other negotiations in BEX and these use
different preference lists encoded as list parameters (e.g., DH list, HIT suite
list). Even the ESP transform parameter (rfc5202, type 4095) has such list.

The question is: is the exception for the transport formats really
good/necessary/justified or should we consider an alternative?

I personally think lifting this exception will make implementations simpler and
less error prone. Especially the checking of the parameter sequence would be

I see two options here:

A) Give all transforms the same type number and an additional sub-type number.
The order of the parameters in the HIP packet would indicate the preference
then. From a handling-point-of-view this option is very similar to as it is now
but there would be just one transform type with subtypes.

Example HIP packet excerpt:
(2096 is an arbitrary type number for the new transport form parameter)
+------+ +------+--------+ +------+--------+ 
|Header| | 2096 | 1| ESP | | 2096 | 2| XYZ | ... 
+------+ +---------------+ +------+--------+
This would mean ESP is preferred, XYZ is not preferred but supported.

B) Give all transforms different type numbers, keep the ordering and express
preference in a list. From a specification-point-of-view this is similar to what we have now.
5202 could stay mostly as it is now.

Example HIP packet excerpt:
(ESP has type number 4095 but for the clarity of the example I use 2095)
+------+ +----+--------------+ +----+---+ +----+---+ 
|Header| |2050|List: ESP, XYZ| |2095|XYZ| |4095|ESP| ... 
+------+ +----+--------------+ +----+---+ +----+---+

Again, this would mean ESP is preferred, XYZ is not preferred but supported.

I prefer option B because it is more similar to other negotiations in BEX.

Any opinions?


Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi