On Wed, 8 Jan 2025, Deb Cooley wrote:
[ speaking as individual enthousiast only ]
I have started the process of rechartering ipsecme. You can see the draft
charter here: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/
Thanks. Some suggestions:
The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), the IPsec security
architecture (RFC 4301), AH (RFC 4302), and ESP (RFC 4303).
Maybe deprioritice IKEv1, eg:
The IPsec suite of protocols includes IKEv2 (RFC 7296 and associated
RFCs), the IPsec security architecture (RFC 4301), AH (RFC 4302), and
ESP (RFC 4303). It also includes the now obsoleted IKEv1 (RFC 2409 and
associated RFCs)
IPsec is widely deployed in VPN gateways, VPN remote access
clients, and as a substrate for host-to-host, host-to-network,
and network-to-network security.
I find the use of "VPN remote access clients" odd, as it is obviously as
much used as "VPN remote access servers" :) Maybe say "VPN remote
access control".
The working group will develop a solution, that allows adding PQC
methods.
Since we have some of the "method" scaffolding in place with
INTERMEDIATE and ADDITIONAL_KE, perhaps rephrase this as:
The working group will develop support for using PQC algorithms.
The solution will allow post quantum authentication methods
to be performed in parallel with (or instead of) the existing
authentication methods.
I think the "in parallel" might be misinterpreted as restricting
solutions or be seen as something different from the ADDITIONAL_KE
method of combining algorithms. Perhaps:
The solution will allow post quantum authentication methods
to be performed on their own or along with the existing
authentication methods.
This work item may also include solutions for transport issues
because of larger payload and message sizes.
I believe this work is already complete with the INTERMEDIATE exchange,
so I think this sentence can be removed?
for example sha3,
Maybe leave that out, as there is a trend now to not specify SHA3 for
use with classic algorithms?
The charter doesn't mention the g-IKEv2 work and any of the other 4
adopted documents in progress. Is that covered under a "maintenance"
part of the charter? I didn't really see that part mentioned, eg
"work on IKEv2 minor extensions". (although g-IKEv2 is not "minor" I
think)
We will need milestones shortly, I'm happy to take suggestions. And per the
usual, comments are welcome.
Milestones for the adopted drafts would be good :)
g-IKEv2 is scheduled for IESG already, so a Milestone of March maybe :)
I think draft-ietf-ipsecme-ikev2-qr-alt-05 is more or less ready as well.
draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-03 needs some work
but once the PFS parts are split into their own doc, might be mostly
waiting on implementation and interop testing. So maybe aim for July?
I am far less clear about the diet-ESP work, which seems stalled and
seems to lack implementer support right now?
Paul
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
