Hi Hannes,
Thank you for pointing out the issue. Actually we wanted to have feed
back from both communities.
- lwig for IoT to make sure we address all or relevant scenarios
of IoT, and understand those we do not address.
- ipsecme for the design of diet-esp.
My understanding is that diet-esp should then be more an ipsecme draft
and minimal esp should be in lwig. We will make this change in the
next version of the draft diet-esp this week!
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
On Sun, Feb 16, 2014 at 8:23 PM, Hannes Tschofenig
<[email protected]> wrote:
> Hi Daniel,
>
> thanks for the pointer to the ipsecme agenda.
>
> I agree with you that ipsecme would be the right place to get this work
> done since the proposal makes changes to IPsec ESP and they have the
> needed experience.
>
> LWIG, as part of the charter, is not allowed to make changes to existing
> protocols, as this snippet from the charter illustrates:
> "
> The group shall also not develop any new protocols or protocol behavior
> modifications beyond what is already allowed by existing RFCs, because
> it is important to ensure that different types of devices can work together.
> "
>
>
> Ciao
> Hannes
>
> On 02/13/2014 02:45 PM, Daniel Migault wrote:
>> Hi,
>>
>> We have not updated the draft to change their names, but I agree they
>> definitely better fit in the LWIG. We would like to present them both
>> in LWIG in London.
>>
>> Note Tero has been provided a 20 minute slot for an overview on "IPsec
>> in constrained environments". So people interested in IoT and security
>> should check the agenda at ipsecme too.
>>
>> [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme
>>
>> On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh
>> <[email protected]> wrote:
>>> Hi Daniel,
>>>
>>> As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT.
>>> However, I think your draft might be useful for LWIG WG though.
>>>
>>> Cheers
>>> Sye Loong
>>>
>>> -----Original Message-----
>>> From: dtls-iot [mailto:[email protected]] On Behalf Of Daniel
>>> Migault
>>> Sent: Friday, 31 January, 2014 10:48 PM
>>> To: [email protected]; [email protected]
>>> Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP
>>>
>>> Hi,
>>>
>>> Please find the two drafts we have just posted. They are about IPsec/ESP
>>> minimal implementation and Diet-ESP designed for IoT.
>>>
>>> Comment are welcome!
>>>
>>> Best Regards,
>>> Daniel
>>>
>>>
>>> Name: draft-mglt-dice-diet-esp
>>> Revision: 00
>>> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP
>>> Document date: 2014-01-31
>>> Group: Individual Submission
>>> Pages: 21
>>> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt
>>> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/
>>> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00
>>>
>>>
>>> Abstract:
>>> IPsec/ESP has been designed to secure IP packets exchanged between
>>> two nodes. IPsec implements security at the IP layer which makes
>>> security transparent to the applications, as opposed to TLS or DTLS
>>> that requires application to implement TLS/DTLS. As a result, IPsec
>>> enable to define the security rules in a similar way one establishes
>>> firewall rules.
>>>
>>> One of the IPsec's drawbacks is that implementing security on a per
>>> packet basis adds overhead to each IP packet. Considering IoT
>>> devices, the data transmitted over an IP packet is expected to be
>>> rather small, and the cost of sending extra bytes is so high that
>>> IPsec/ESP can hardly be used for IoT as it is currently defined in
>>> RFC 4303.
>>>
>>> This document defines Diet-ESP, a protocol that compress and reduce
>>> the ESP overhead of IPsec/ESP so that it can fit security and energy
>>> efficient IoT requirements. Diet-ESP use already existing mechanism
>>> like IKEv2 to negotiate the compression format. Furthermore a lot of
>>> information, already existing for an IPsec Security Association, are
>>> reused to offer light negotiation in addition to maximum compression.
>>>
>>>
>>> Name: draft-mglt-lwig-minimal-esp
>>> Revision: 00
>>> Title: Minimal ESP
>>> Document date: 2014-01-31
>>> Group: Individual Submission
>>> Pages: 6
>>> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt
>>> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
>>> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00
>>>
>>>
>>> Abstract:
>>> This document describes a minimal version of the IP Encapsulation
>>> Security Payload (ESP) described in RFC 4303 which is part of the
>>> IPsec suite.
>>>
>>> ESP is used to provide confidentiality, data origin authentication,
>>> connectionless integrity, an anti-replay service (a form of partial
>>> sequence integrity), and limited traffic flow confidentiality.
>>>
>>> This document does not update or modify RFC 4303, but provides a
>>> compact description of the minimal version of the protocol. If this
>>> document and RFC 4303 conflicts then RFC 4303 is the authoritative
>>> description.
>>>
>>>
>>> --
>>> Daniel Migault
>>> Orange Labs -- Security
>>> +33 6 70 72 69 58
>>> _______________________________________________
>>> dtls-iot mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/dtls-iot
>>
>>
>>
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
