https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/

now references diet-esp.

I am ready to add my efforts on the diet-esp document.  I DO want it to get a SCHC IP port number so SCHC can be the ESP Next Header value.

Also so IP itself can use SCHC for the diet-ESP if needed where there is no below IP SCHC in action (and maybe even if).

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 <kivi...@iki.fi> 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

Reply via email to