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" <[email protected]>
To: "Daniel Migault" <[email protected]>; "Hannes Tschofenig"
<[email protected]>
Cc: <[email protected]>; <[email protected]>; "Sye Loong Keoh"
<[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
