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
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
