Hi Antony,
> Hi Wei Pan,
>
> On Sun, Nov 03, 2024 at 03:50:26PM +, Panwei (William) wrote:
> > Hi Scott,
> >
> > Thank you very much for your comments.
> >
> > What you suggested is actually we proposed in draft v00. In our last
> > version,
> the notification only contains the status of rep
Hi Wei Pan,
On Sun, Nov 03, 2024 at 03:50:26PM +, Panwei (William) wrote:
> Hi Scott,
>
> Thank you very much for your comments.
>
> What you suggested is actually we proposed in draft v00. In our last version,
> the notification only contains the status of replay protection, and after
> b
Hi Scott,
Thank you very much for your comments.
What you suggested is actually we proposed in draft v00. In our last version,
the notification only contains the status of replay protection, and after both
peers exchanged this notification, they can choose not to do the sequence
number monitor
Here is updated IPsecME agenda (I did not receive any
presentations for the diet draft, so I rolled those items in to the
document status presentation).
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 121 - Monday, N
Internet-Draft draft-ietf-ipsecme-ikev2-diet-esp-extension-01.txt is now
available. It is a work item of the IP Security Maintenance and Extensions
(IPSECME) WG of the IETF.
Title: Internet Key Exchange version 2 (IKEv2) extension for Header
Compression Profile (HCP)
Authors: Daniel Migau
I just went through this draft, and I think the problem (which is "why do we
avoid rekeying after 2^32 packets if replay is not enabled") is actually
simpler than what the authors expect.
Solution 1:
The note about ESN and antireplay is (section 3.3.3)
If a receiver chooses to not enable an
