Hi,
> I think the best way to make them work is to keep the individual
> payload length less than 64k, but QSKE (or whatever the new payload is
> called) so that it can provide separate pieces of actual KE payload.
That's exactly what I suggested in
Thank you Scott for your comments.
I understand the first comment as a text clarification to comment on the
mechanism provided by section 3.5 of RFC6407 and explicitely mention that
is does not apply here. Does the replacement below addresses your concern ?
OLD:
Section 3.5 of [RFC6407]
Thanks a lot Scott for the response. I am publishing the draft asap.
Yours,
Daniel
On Tue, Mar 27, 2018 at 2:04 PM, Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:
>
>
> *From:* mglt.i...@gmail.com *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, March 27, 2018 1:22
From: mglt.i...@gmail.com On Behalf Of Daniel Migault
Sent: Tuesday, March 27, 2018 1:22 PM
To: Scott Fluhrer (sfluhrer)
Cc: IPsecme WG (ipsec@ietf.org)
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-implicit-iv
Thank you Scott for
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions WG of
the IETF.
Title : Implicit IV for Counter-based Ciphers in
Encapsulating Security Payload (ESP)
Authors