[IPsec] Diet-ESP

Daniel Migault <mglt.ietf@gmail.com> Fri, 04 July 2014 20:16 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09CA1B2F4C; Fri, 4 Jul 2014 13:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj8AH9CY-BCm; Fri, 4 Jul 2014 13:16:16 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2401B2F4A; Fri, 4 Jul 2014 13:16:16 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id n15so13484480wiw.10 for <multiple recipients>; Fri, 04 Jul 2014 13:16:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GenD7SMxAY7EtlDAzopeWOe63KC+445mVtlXIqjuucI=; b=AeMfc6V44rIsJ0t57fJTVoz3AAfImtJ0XghGcXvaRdI1LuDrE2D8+B2WYp936wWeAB ljsrMFs87cE4k7EFl++t9ryrIRIdtGP2fB2tNZrePejPkUWfewJFi/TbVDtWzIdVyZ2Y 1bxwH3pGWSyecO40cfKoYExF3Q05gnc43e6Pqyzi3mAAth8qjBuv/rG3/duUh8iPbzIc 5tGusNlXkQWbuGbxR9GViQdcwrDsr6GoEqsvszycM/AhZ7ZzFpvLuswh44rmr9E//HXz nZKZD53u97PelynqC2r5dcSME8cIKm147adwTCfQp2EHGjkq0j2yc4MGIsByDkXF5h7Y hXSw==
MIME-Version: 1.0
X-Received: by 10.180.106.66 with SMTP id gs2mr20512644wib.5.1404504975014; Fri, 04 Jul 2014 13:16:15 -0700 (PDT)
Received: by 10.194.51.131 with HTTP; Fri, 4 Jul 2014 13:16:14 -0700 (PDT)
Date: Fri, 04 Jul 2014 22:16:14 +0200
Message-ID: <CADZyTk=DUkRDX8sfXLS+HTqGw61ZMPexMC9yQadnKd4z9HwmGg@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: 6lo@ietf.org, "ipsec@ietf.org" <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="f46d04451a0d1f011904fd63cca8"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-PekVpGuwZENXjqOXSKbZp_i5ZM
Subject: [IPsec] Diet-ESP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 04 Jul 2014 20:16:18 -0000

Hi,

Here are the drafts we wrote on Diet-ESP which designs ESP for constrain
environment.

[1] draft-mglt-ipsecme-diet-esp-requirements-00.txt
<http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-requirements/>
provides the requirements we considered for the design of Diet-ESP
[2] draft-mglt-ipsecme-diet-esp-01.txt
<http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/>
describes Diet-ESP. According to feed backs we received during the
last presentation. Diet-ESP does not modify ESP. Instead, we consider
compression / decompression of the payload sent on the wire.
[3] draft-mglt-ipsecme-diet-esp-iv-generation-00.txt
<http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-iv-generation/>
describes a way to compress th IV field in ESP encrypted payloads.
[4] draft-mglt-ipsecme-diet-esp-payload-compression-00.txt
<http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-payload-compression/>
describes how IPsec parameters negotiated with IKEv2 can be used to
compress the clear text payload. More specifically, it is expected to
compress up to the transport layer of the encrypted packet.

Feel free to make comments!

We have specific question regardin the IV compression. The general idea is
that a speudo random function is used on bth side to generate the IV. This
makes possible to send only some LSB.
    - 1) The pseudo random function uses as input the encryption key an
dthe authentication key. I do not see major security flaws, but it may be
better if a dedicated K could be used. Any ideas?
    - 2) By default we use PRF_AES128_XCBC. Another way would consist in
chosing the PRF based on the ICV function. When NULL authentication is used
the IV would not be compressed. Any opinion on that too?


[1]
http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-requirements/
[2] http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
[3]
http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-iv-generation/
[4]
http://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp-payload-compression/
-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58