Re: [IPsec] Transport ESP and SCHC
I am reading diet-esp right now, and from what you said, will skip
minimal-esp at least for now, as I have too much else on my plate (as
you well know).
SCHC is explicitly called out in the Intro without referencing the
drafts of the time. To avoid any blocking drafts? Would you now have
8724 as a normative reference? I would think you would need that for
the IANA section to ask for the protocol number?
For my use case, it is ESP in transport, and most likely only with UDP
(but would not want to risk boxing UAs into that corner).
I will read some more, but I do think that the SCHC rule ID will be both
below to compress ESP, and above for the transport/application. But I
am suredly getting ahead of myself...
Bob
On 5/3/22 16:56, Daniel Migault wrote:
minimal esp describes how to implement a standard ESP in a constrained
environment with minimal options as well as variants to minimize the
impact of the implementation on the device.
diet-esp defines how to compress / decompress ESP. The description is
pretty much complete. We implemented it on Contiki. We were wondering
whether to adapt with SCHC. It would be cleaner in my opinion, but
that is just a thought.
Yours,
Daniel
On Tue, May 3, 2022 at 4:44 PM Robert Moskowitz
wrote:
Daniel and Tero,
How do diet-esp and minimal-esp intersect?
minimal-esp is, it seems ready for publication, so nothing really
changing it is possible.
But what does diet-esp do instead?
Squeezing down esp and adding support for SCHC ('easy' by adding
it as an IP Protocol) is of interest to me...
Bob
On 4/21/22 10:36, Daniel Migault wrote:
The question we are asking ourselves is should we re-write the
spec with SCHC.
Yours,
Daniel
On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
Robert Moskowitz writes:
> Yet in 8724, they define a in-band header:
>
> |--- Compressed Header ---|
>
> +-++
>
> | RuleID | Compression Residue | Payload |
>
> +-++
>
> How do you include this? This is especially needed
with CoAP, rfc 8824.
>
> What is preconfigured is what does the RuleID instruct
you to do with that
> compression residue.
>
> A bit more on this. When above Transport as in 8824, the
port number needs to
> know how to process the RuleID. When below IP as in 9011,
the MAC needs a
> type assigned for SCHC to know to use the RuleID for
IP/whatever expansion.
> MAC types are not the IETF's problem.
>
> It takes something like ESP that sits below Transport, to
change this. Thus
> this COULD be an lpwan issue for introducing SCHC, or it
could be an ipsecme
> issue as as far as I can think, only ESP presents this issue.
You might want to check the Diet ESP work that was done in
the IPsecME
WG few years back. It mostly died because there was not enough
interest to work on the drafts or implementations.
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
This is still in the IPsecME charter item so if there is
interest to
start working on this then IPsecME WG has space for it:
A growing number of use cases for constrained networks -
but not
limited to those networks - have shown interest in
reducing ESP
(resp. IKEv2) overhead by compressing ESP (resp IKEv2)
fields. The
WG will define extensions of ESP and IKEv2 to enable ESP
header
compression.
Possible starting points are draft-mglt-ipsecme-diet-esp,
draft-mglt-ipsecme-ikev2-diet-esp-extension,
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Transport ESP and SCHC
minimal esp describes how to implement a standard ESP in a constrained
environment with minimal options as well as variants to minimize the impact
of the implementation on the device.
diet-esp defines how to compress / decompress ESP. The description is
pretty much complete. We implemented it on Contiki. We were wondering
whether to adapt with SCHC. It would be cleaner in my opinion, but that is
just a thought.
Yours,
Daniel
On Tue, May 3, 2022 at 4:44 PM Robert Moskowitz
wrote:
> Daniel and Tero,
>
> How do diet-esp and minimal-esp intersect?
>
> minimal-esp is, it seems ready for publication, so nothing really changing
> it is possible.
>
> But what does diet-esp do instead?
>
> Squeezing down esp and adding support for SCHC ('easy' by adding it as an
> IP Protocol) is of interest to me...
>
> Bob
>
> On 4/21/22 10:36, Daniel Migault wrote:
>
> The question we are asking ourselves is should we re-write the spec with
> SCHC.
>
> Yours,
> Daniel
>
> On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
>
>> Robert Moskowitz writes:
>> > Yet in 8724, they define a in-band header:
>> >
>> >|--- Compressed Header ---|
>> >
>> >+-++
>> >
>> >| RuleID | Compression Residue | Payload |
>> >
>> >+-++
>> >
>> > How do you include this? This is especially needed with CoAP, rfc
>> 8824.
>> >
>> > What is preconfigured is what does the RuleID instruct you to do
>> with that
>> > compression residue.
>> >
>> > A bit more on this. When above Transport as in 8824, the port number
>> needs to
>> > know how to process the RuleID. When below IP as in 9011, the MAC
>> needs a
>> > type assigned for SCHC to know to use the RuleID for IP/whatever
>> expansion.
>> > MAC types are not the IETF's problem.
>> >
>> > It takes something like ESP that sits below Transport, to change this.
>> Thus
>> > this COULD be an lpwan issue for introducing SCHC, or it could be an
>> ipsecme
>> > issue as as far as I can think, only ESP presents this issue.
>>
>> You might want to check the Diet ESP work that was done in the IPsecME
>> WG few years back. It mostly died because there was not enough
>> interest to work on the drafts or implementations.
>>
>> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
>>
>> This is still in the IPsecME charter item so if there is interest to
>> start working on this then IPsecME WG has space for it:
>>
>> A growing number of use cases for constrained networks - but not
>> limited to those networks - have shown interest in reducing ESP
>> (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The
>> WG will define extensions of ESP and IKEv2 to enable ESP header
>> compression.
>>
>> Possible starting points are draft-mglt-ipsecme-diet-esp,
>> draft-mglt-ipsecme-ikev2-diet-esp-extension,
>> draft-smyslov-ipsecme-ikev2-compression and
>> draft-smyslov-ipsecme-ikev2-compact.
>> --
>> kivi...@iki.fi
>>
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>
> --
> Daniel Migault
> Ericsson
>
> ___
> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>
>
>
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Transport ESP and SCHC
Daniel and Tero,
How do diet-esp and minimal-esp intersect?
minimal-esp is, it seems ready for publication, so nothing really
changing it is possible.
But what does diet-esp do instead?
Squeezing down esp and adding support for SCHC ('easy' by adding it as
an IP Protocol) is of interest to me...
Bob
On 4/21/22 10:36, Daniel Migault wrote:
The question we are asking ourselves is should we re-write the spec
with SCHC.
Yours,
Daniel
On Thu, Apr 21, 2022 at 9:58 AM Tero Kivinen wrote:
Robert Moskowitz writes:
> Yet in 8724, they define a in-band header:
>
> |--- Compressed Header ---|
>
> +-++
>
> | RuleID | Compression Residue | Payload |
>
> +-++
>
> How do you include this? This is especially needed with
CoAP, rfc 8824.
>
> What is preconfigured is what does the RuleID instruct you
to do with that
> compression residue.
>
> A bit more on this. When above Transport as in 8824, the port
number needs to
> know how to process the RuleID. When below IP as in 9011, the
MAC needs a
> type assigned for SCHC to know to use the RuleID for IP/whatever
expansion.
> MAC types are not the IETF's problem.
>
> It takes something like ESP that sits below Transport, to change
this. Thus
> this COULD be an lpwan issue for introducing SCHC, or it could
be an ipsecme
> issue as as far as I can think, only ESP presents this issue.
You might want to check the Diet ESP work that was done in the IPsecME
WG few years back. It mostly died because there was not enough
interest to work on the drafts or implementations.
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/07/
This is still in the IPsecME charter item so if there is interest to
start working on this then IPsecME WG has space for it:
A growing number of use cases for constrained networks - but not
limited to those networks - have shown interest in reducing ESP
(resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The
WG will define extensions of ESP and IKEv2 to enable ESP header
compression.
Possible starting points are draft-mglt-ipsecme-diet-esp,
draft-mglt-ipsecme-ikev2-diet-esp-extension,
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact.
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
