Re: [IPsec] Virtual interim about re-designing ESP?

I want to add support of constrained communications and taking diet-esp 
to the next step as we work in lpwan with SCHC as a protocol.

The low byte overhead of DTLS makes it very attractive in constrained 
communications.  How can we best pair SCHC with ESP for efficient use of 
limited resources.

Also how to negotiate SCHC rules between parties.  In the lpwan session 
we discussed secure channel for SCHC rule negotiation. ike-diet-esp is a 
great starting point with the potential challenges.  Does this happen in 
IPsecme or lpwan?  How to coordinate?

A should also point out that SCHC provides ARQ and we are planning on 
adding FEC.  This should be transparent to ESP, but is there any 
considerations for improved transmission reliablity?

Bob

On 11/22/22 13:29, Michael Richardson wrote:
> Steffen Klassert <steffen.klassert@secunet.com> wrote:
>      > at the last working group meeting in London, it was quite some interest
>      > to work on a re-design of ESP to make it fit to the multi-cpu case, QoS
>      > classes, HW offloads etc.
>
> I agree with your idea in the subject, of a virtual interim on this.
>
>      > https://www.ietf.org/archive/id/draft-ponchon-ipsecme-anti-replay-subspaces-00.txt
>
> While there is a problem space section in this document, I found it a bit inadequate.
> I think that it is important to collect all of the challenges into a single
> set of goals.
>
>      > The Google PSP Security Protocol (PSP) is another new 'ESP like'
>      > protocol. There is some interest to standardize PSP, so the issues that
>      > are solved there should also be considered when designing a new ESP
>      > version. Most concepts that are used in PSP are taken from IPsec ESP,
>      > so IMO this should be integrated into the IPsec protocol suite.
>
> It would be great to have the problems/challenges that this aims to solve, as
> well as the RAVSI concepts there too.
>
>      > - What are the problems to solve?
>
> Let's get consensus on this aspect first.  Maybe there are things that we
> might agree are out-of-scope, or are really implementation specific issues.
> That might mean a document be written, and the WG do a consensus call.
>
>      > - How should the problems be solved?
>      > Please let me know if there is interest,
>
> Thank you for bringing this up.
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec