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

[Yaron Sheffer <[e-mail]>]

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
>