Let me reply to Hannes’ statement: “Integrating the functionality into SCHC
alone is not enough.”
I consider SCHC as a technical mean and not an end. I.e., it is not about
adding IPsec to SCHC but rather about using SCHC to compress IPsec (= ESP &
IKE). The SCHC WG did a similar work with COAP.
Internet-Draft draft-ietf-ipsecme-ikev2-auth-announce-06.txt is now available.
It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG
of the IETF.
Title: Announcing Supported Authentication Methods in IKEv2
Author: Valery Smyslov
Name:draft-ietf-ipsecme-ikev2-
Hi,
the -06 version has the security considerations section updated.
Regards,
Valery.
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, December 12, 2023 4:09 PM
> To: i-d-annou...@ietf.org
> Cc: ipsec@ietf.org
>
Hi Hannes,
Seems I did not click "sent" yesterday. Please see my response inline.
Yours,
Daniel
On Mon, Dec 11, 2023 at 12:02 PM Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Daniel, Hi all,
>
>
> don't get me wrong: I am trying to be helpful.
>
>
> This is how I am reading your co
Hi Paul,
reading your response it sounds to me that a myth busting (or a hitchhiker's
guide to IKEv2/IPsec) document would be useful. I am curious whether others
have also run into similar discussions about Wireguard.
Additionally, it seems worthwhile to think about doing something simil
Hi Eric,
I think we are saying the same thing. Making the SCHC integration will be nice
but does not get you to solve anything for constrained IoT device
implementations.
Ciao
Hannes
From: Eric Vyncke (evyncke)
Sent: Dienstag, 12. Dezember 2023 12:34
To: Hannes Tschofenig ; Daniel
Hi Daniel,
thanks for your response. See my response below.
From: Daniel Migault
Sent: Dienstag, 12. Dezember 2023 15:20
To: Hannes Tschofenig
Cc: Hannes Tschofenig ; Carsten
Bormann ; Tero Kivinen ; ipsec@ietf.org;
s...@ietf.org
Subject: Re: [IPsec] WG Adoption calls for draft-mglt-ip
Pierre Pfister (ppfister) writes:
> > Sending 144 small encrypted packets, and receiving 144 small encrypter
> > packets should not take lots of CPU power. The CREATE_CHILD_SA does
> > NOT need to do any Diffie-Hellman, and there is no public key crypto
> > on them, so it is just encrypting those p
Antony Antony writes:
> > What we are saying is do this:
> >
> > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for
> > Child SA)
> > T=00:01 Establish 2nd Child SA using DH (lifetime 8h)
> > T=01:00 Rekey IKE SA
> > T=02:00 Rekey IKE SA
> > [...]
> > T=07:00 Rekey IK
