Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP

"Valery Smyslov" <svanru@gmail.com> Wed, 26 February 2014 06:47 UTC

Return-Path: <svanru@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 90FCA1A047C; Tue, 25 Feb 2014 22:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 IUyTIJPK04QC; Tue, 25 Feb 2014 22:47:01 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D31A046F; Tue, 25 Feb 2014 22:47:00 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id hr13so311264lab.17 for <multiple recipients>; Tue, 25 Feb 2014 22:46:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=TDze3BTU83oMmZI7m8bPw2RE3+Glu2iYNO8ChS6ZiX4=; b=Q0XyADY5zKz1OckVgnsmufLaLgRsJz1TkqVPaXB73OdVbdarxoRGI43j44acewczUB P4h5ps1wFE/A/LhNtlK6tHCVUIClskJUgeJ8ILfD2HXbpZoaIYUwq/yitZ1qZIHLgKrQ 51A5c4ePAf2TXzcJrDkToQocYL+wt77yQksFobUuQCcbzZDeoT64HCK8KM4HXgLxA5rG UPICybsr3cF5s/8VSbOJt4/pJUqlWF761l7YrB1K5k/rKl1D0VwMp/6L8ajPBjo26XnE kkAhoJpjkvbD8jiE1UavZ58Zo13Cvioj7CaAxKh5Z8rHE/ywpFl4tGWvmjgZV7ksH+e2 Q6qQ==
X-Received: by 10.152.23.132 with SMTP id m4mr1162125laf.34.1393397218753; Tue, 25 Feb 2014 22:46:58 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mo3sm24849628lbb.17.2014.02.25.22.46.57 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Feb 2014 22:46:58 -0800 (PST)
Message-ID: <F1954BB774EA4C7DAA729D2623D8F364@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Yaron Sheffer" <yaronf.ietf@gmail.com>, "Daniel Migault" <mglt.ietf@gmail.com>, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
References: <CADZyTk=k3=-BN=8ma=beMh9b0skswW-SvmbP9Ae2AOQwbV0k-Q@mail.gmail.com> <530393EA.5020008@gmail.com>
Date: Wed, 26 Feb 2014 10:47:09 +0400
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AEXgkMSJT66ADwjPOtnc-sX0KgA
Cc: ipsec@ietf.org, lwip@ietf.org, Sye Loong Keoh <SyeLoong.Keoh@glasgow.ac.uk>
Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal 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: Wed, 26 Feb 2014 06:47:03 -0000

Hi,

First, I agree with Yaron that Diet-ESP looks more like a new protocol,
than like ESP extension. And in this case it must have its own
protocol number.

Then, I have some concerns how Diet-ESP will live with NATs.
The draft is silent about it. If we consider Diet-ESP as ESP
extension, then standard UDP-encapsulation must apply.
But here is the problem - with UDP encapsulation the first
4 bytes of packet data are used to distinguish between
IKE and UDP-encapsulated ESP, as in ESP these bytes
are SPI wich is never zero. In Diet-ESP this is not true -
SPI may be shorter than 4 bytes or even be absent and
there is a chance that those bytes will be zero (e.g. an IV
may appear to be zero, and SPI and SN are absent).
So, with Diet-ESP we cannot reliably distinguish IKE
from UDP-encapsulated ESP and therefore some other
mechanism must be (re)invented.

And last, the draft declares that its main goal is to minimize
power consumption caused by transferring extra bytes.
But in this case it's probably more fruitful to define some
new crypto transform for IoT, than redesigning ESP. In this
case you may use implicit IV (or explicit, but small),
small ICV, use stream cipher etc. I think
that in this case you may gain even more economy
in power consumption than with current approach.

Regards,
Valery Smyslov.




----- Original Message ----- 
From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
To: "Daniel Migault" <mglt.ietf@gmail.com>om>; "Hannes Tschofenig" 
<hannes.tschofenig@gmx.net>
Cc: <ipsec@ietf.org>rg>; <lwip@ietf.org>rg>; "Sye Loong Keoh" 
<SyeLoong.Keoh@glasgow.ac.uk>
Sent: Tuesday, February 18, 2014 9:10 PM
Subject: Re: [IPsec] [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP


> Hi Daniel,
>
> This might be a naive answer - I have not read the draft in detail.
>
> But on the "is this a duck or not" question, it seems to me the answer is 
> simple: if the protocol can work stand-alone (two endpoints talking to 
> each other, with manual keying and no IKE), then it's a protocol. 
> Otherwise it's a protocol extension.
>
> And if it's a protocol, it needs an IP protocol number, which is a 
> seriously expensive resource. We allocated one for WESP 
> (http://tools.ietf.org/html/rfc5840#section-4), is there any chance we 
> could reuse it somehow?
>
> Thanks,
> Yaron
>
> On 02/18/2014 03:06 PM, Daniel Migault wrote:
>> Hi Hannes,
>>
> [...]
>
>>
>> Now comes also another question: Is diet-ESP a new protocol, a new
>> extension, a ESP compression algorithm.... I would be happy to get
>> opinion on that.
>>
>> 1) Diet-ESP: Extension vs Protocol
>>
>>      - a) Diet-ESP is an IPsec extension
>> The way we considered to peers agreeing on the diet-esp context is
>> using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with
>> proposition of DIET-ESP Context. The responder just ignores the
>> propositions or chose one. All remaining stuff would be negotiated via
>> the traditional CREATE_CHILD_SA were peers would agree on ESP, keys,
>> algos....
>>>From that point of view it looks the diet-ESP is more a
>> wire-compression algorithm. If not supported by one of the peer we
>> fall back with standard ESP.
>>
>>      -b) Diet-ESP is a new Protocol
>> Another way would be to consider that all parameters of the Diet-ESP
>> Context would be negotiated in the CREATE_CHILD_SA exchange with new
>> Transform structures.
>>>From that point of view diet-esp would look more like a new protocol
>> and the possible choice may be IKE/ESP/AH/DIET-ESP....
>>
>>   There might be other alternatives I would be happy to hear about. For
>> now I like better the extension way.
>>
>> 2) What Diet-ESP changes from regular ESP
>>
>> Diet-ESP changes IPsec and ESP headers, trailers with smaller fields.
>>
>> Diet-ESP changes the way the packet is compressed and encrypted.
>>
>> On the other hand, for a sensor with a single diet-ESP configuration,
>> most of the IPsec stack remains unchanged. This is not so true for
>> peers that are able to handle all Diet-ESP configuraions. In that case
>> the standard way of looking up in the SAD may be changed. We will
>> provide a better description of this in the next version of the draft.
>>
>> BR,
>> Daniel
>>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec