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 : Group Key Management using IKEv2
Authors : Valery Smyslov
B
Hi,
a new version of the draft contains no changes - just to prevent draft
expiration.
Regards,
Valery.
> 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.
>
>
Hi Paul,
thanks a lot for your review.
> I have reviewed the changed between draft-ietf-ipsecme-rfc8229bis and
> RFC 8229. I agree with most of these changes. I have some comments
> below. If others want to compare the draft with the RFC, see:
>
> https://nohats.ca/draft-ietf-ipsecme-rfc8229bis-
On Mon, 10 Jan 2022, Valery Smyslov wrote:
I am not sure this is a good idea. Tearing down and requiring a new 3way
handshake just to deliver the cookie seems useless. What is wrong with
using the existing TCP stream to reply?
The responder does use an existing TCP connection to reply,
but onc
While reading the draft-ietf-ipsecme-g-ikev2-04 draft I started to
thinking whether we should get rid of the GSA_AUTH completely?
We have several extensions or enhancements that change the way
IKE_SA_INIT and IKE_AUTH are done, and porting those changes to the
GSA_AUTH is going to require extra wo
Valery Smyslov writes:
> The responder does use an existing TCP connection to reply, but once
> it replies with cookie request, it should close this connection. If
> it keeps this connection, then it keeps TCP state until the client
> resends IKE_SA_INIT request (if ever) and thus thwarts the idea
Hi all,
The core mechanisms here seem in good shape. My main area of
uncertainty relates to how much analysis, and with what degree of
formalism, has been applied to the updated IKE_AUTH procedures that are
supposed to authenticate the intermediate exchange(s). My comments on
ยง3.3.2 have more de
