Scott Fluhrer \(sfluhrer\) writes:
> My comment "this shouldn't block draft-ietf-ipsecme-ikev2-mlkem was aimed at
> the working group, and not to the draft authors.
>
> That said, to the working group, what is blocking
> draft-ietf-ipsecme-ikev2-mlkem? The draft is needed, quite straight-forward,
Yuta Fukagawa writes:
> I submitted the presentation slide "- draft-skyline-ipsecme-ntru-ikev2 - Yuta
> Fukagawa”, so please check it.
Thank you, approved now.
--
kivi...@iki.fi
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to i
I really need to get the slides for the IETF 123 IPsecME presentations
as soon as possible. I will make the combined slideset today, so if
there are no slides submitted to datatracker / to chairs before that
we will skip that presentation tomorrow.
I now have following slides:
- Enhanced ESP
- dr
Jun Hu \(Nokia\) writes:
> ● Sure, downgrade attack also works for hybrid if initial DH is weak, but
> you could use ML-KEM as the initial DH (I understand concern of having
> large IKE_SA_INIT packet, but it could work in network support large mtu)
> ● In hub-and-spoke case, gateway ha
Yoav Nir writes:
> Hi, all
>
> I’ve thrown together an initial agenda.
> https://datatracker.ietf.org/meeting/123/materials/agenda-123-ipsecme-01.md
>
> The agenda is quite full, although maybe we can squeeze a little
> more. There’s a whole lot of post-quantum stuff in there -
> definitely the
As our charter is now updated, this document is working on the
following charter item:
Post-quantum Cryptography (PQC) brings new authentication and
key establishment methods. The working group will develop
support for using PQC algorithms.
This email will start three week
As our charter is now updated, this document is working on the
following charter item:
The ESPv3 protocol was defined in 2005 and there may be a need
to make enhancements to it. The working group will analyze the
possible problems and work on solving them. This may include
As our charter is now updated, this document is working on the
following charter item:
The ESPv3 protocol was defined in 2005 and there may be a need
to make enhancements to it. The working group will analyze the
possible problems and work on solving them. This may include
David Dong via RT writes:
> Dear Tero Kivinen (cc: ipsecme WG, Valery Smyslov),
>
> As a designated expert for the IKEv2 Notify Message Status Types
> registry, can you review the proposed registration in
> draft-ietf-ipsecme-ikev2-qr-alt-07 for us? Please note that Valery
> is
Jen Linkova writes:
> In the earlier thead
> (https://mailarchive.ietf.org/arch/msg/ipsec/QwhMVZqByAZ4YPtvZxLfi83PATw/)
> a number of people expressed their support for both drafts.
> Will their voices be taken into account, or shall they reply to this thread?
That was WG chair finding out what ki
As our charter is now updated, this document is working on the
following charter item:
There is a need for tools that make it easier to debug IPsec
configurations. The working group will work on documents to
help that. One such tool could be the esp-ping protocol.
This ema
As our charter is now updated, this document is working on the
following charter item:
There is a need for tools that make it easier to debug IPsec
configurations. The working group will work on documents to
help that. One such tool could be the esp-ping protocol.
This ema
I finally found out few minutes time to collect the agenda requests
and create the agenda for the IETF 122.
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 122 - Tuesday, March 18th, 2025 13:00-15:00
https://meetings
Tero Kivinen has requested publication of draft-ietf-ipsecme-ikev2-qr-alt-06 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-q
This email starts two week working group adoption call for
draft-antony-ipsecme-iekv2-beet-mode [1] document. If you are in favor
of adoption this document as working group document, please reply to
this email and say so. And especially if you have any objections for
adopting this document as WG do
We have draft-colitti-ipsecme-esp-ping [1] and
draft-antony-ipsecme-encrypted-esp-ping [2] both of which propose ESP
ping, but on the different level, and each of those provide different
level of debugging capabilities.
The question I have for the WG, do we need both?
If we only need one, which o
Antony Antony writes:
> Dear WG Chairs,
>
> This is a friendly nudge for your response, as the re-chartering
> process seems to have progressed.
>
> Could you please let us know the next steps? Would the WG Chairs
> consider issuing a call for WG adoption of this document?
Yes, I think I can sta
As our charter is now updated, this document is working on the
following charter item:
Post-quantum Cryptography (PQC) brings new authentication and key
establishment methods. The working group will develop support for
using PQC algorithms. The solution will allow post quantum
auth
Éric Vyncke via Datatracker writes:
> Just two comments on "The working group will work on documents to
> help that. One such tool could be the esp-ping protocol."
>
> 1) should there be a reference to the ESP-ping (especially as it
> appears in the milestones) ?
We currently have two different p
Daniel Migault writes:
> I am unclear about the implications of the suggestion, as I do not find any
> reference to ESP Compression in the charter or the milestones. I am wondering
> if I may be overlooking a crucial aspect of the discussion. Additionally,
> there is a minor typo in the draft name;
I was looking that mailing list discussion about the WGLC of the
draft-ietf-ipsecme-ikev2-qr-alt and there were several people who
commented about this draft and Valery answered to them, but I did not
get comments back from those who made those comments whether they
think that their comments have b
This will start two week WGLC for the
draft-ietf-ipsecme-ikev2-diet-esp-extension [1]. This last call will
end at 2025-01-23. If you have any comments about the draft send them
to the WG list.
[1]
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-diet-esp-extension/
--
kivi...@iki.fi
__
This will start two week WGLC for the draft-ietf-ipsecme-diet-esp [1].
This last call will end at 2025-01-23. If you have any comments about
the draft send them to the WG list.
[1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-diet-esp/
--
kivi...@iki.fi
___
Paul Wouters writes:
> 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?
No. This also includes things usi
Michael Richardson writes:
> I was going through documents, and I was supprised that when we made
> RFC7296 into STD79, that we didn't include RFC4301 into STD79. (and
> maybe 4302 and 4303)
The reason STD79 only has IKEv2 is because that was only thing that
was needed. The reason we moved IKEv2 t
Deb Cooley writes:
> (to loop in Yoav)
>
> Tero,
>
> I see a message on 3 Dec, which declares the charter draft complete. Then
> there were 3-4 comments to that message (I have not read them in detail, so
> I'm not pushing you either to include or not). Can you confirm that your
> draft charter
Tero Kivinen has requested publication of
draft-ietf-ipsecme-ikev2-rename-esn-01 as Proposed Standard on behalf of the
IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-renam
Paul Wouters writes:
> On Sun, 15 Dec 2024, Valery Smyslov wrote:
> > So, my question: what term should we use to be aligned with RFC
> > 4301-4303 and to not confuse readers? Perhaps this is a
> > bikeshedding, but an important one.
Oh, my shepherd writeup already mentions this:
2. Was there
While doing the shepherd writeup, I need to know whether there are any
IPRs anybody is aware related to this draft.
Valery, can you reply to this email stating whether there is any IPRs
that you know that would be releavant to this draft.
If anybody else has any IPRs that they know reply to this
We are now done with the WGLC draft-ietf-ipsecme-ikev2-rename-esn. I
think there were few comments from Paul that at least caused changes
to the draft, so after we get updated draft I can send it to the IESG.
--
kivi...@iki.fi
___
IPsec mailing list --
nybody responding to them, so I will respond to them
separately in that email.
> Thank you!
>
> Best regards,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Tue Dec 03 14:23:51 2024, kivi...@iki.fi wrote:
> > David Dong via RT writes:
> > > Dear Tero
Valery Smyslov writes:
> one potential problem, that I want to be resolved, is the status of
> this document.
>
> Currently it is an Informational document, since it doesn't define
> any protocol (and in fact it doesn't even have any RFC 2119
> language). But it updates RFC 7296, which is a Standa
As we talked earlied when doing g-ikev2 IETF last call, the text
talking about renaming ESN transform type got separated to this new
draft, and this will start one (1) week working group last call of the
draft.
I try to make this fast so it can catch up the g-ikev2 draft (which is
in IETF LC until
Michael Richardson writes:
>
> Tero Kivinen wrote:
> > Postquantum Cryptography brings new authentication methods. The
>
> (rant about "quantum-safe" term omitted)
>
> ...
>
> > The ESPv3 protocol was defined in 2005 and there has been seen th
We have now finished our discussion about the IPsecME WG rechartering.
Here is the proposed new charter:
--
The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), the
David Dong via RT writes:
> Dear Tero Kivinen, (cc: ipsecme WG),
>
> As a designated expert for the Internet Key Exchange Version 2
> (IKEv2) Parameters registries, can you review the proposed
> registrations in draft-ietf-ipsecme-g-ikev2-17 for us? Please note
> that Vale
Antony Antony writes:
> For the transform name, I prefer Anti-Replay Protection (ARP), as
> Anti-Replay Service is already a term used in the IPsec architecture
> document RFC 4301. I believe keeping this name
> for the transform aligns well with the terminology. Please read 4301 before
> sugge
Daniel Migault writes:
> In a charter discussion, references to drafts typically serve to demonstrate
> that some progress has been made or is currently underway within the solution
> space. These drafts are presented as a starting point, which does not preclude
> the consideration of alternative p
Valery Smyslov writes:
> Some candidates:
>
> Sequence Number Properties (SNP)
> Sequence Number Interpretation (SNI) (can be mixed up with SNI in TLS)
> Sequence Number Features (SNF)
>
> Thoughts? Other proposals?
All of those works for me, just pick whatever you like. SNP sounds
fine...
Antony Antony writes:
> I have a minor clarification question.
> Would this cover the work proposed in draft-antony-ipsecme-ikev2-beet-mode?
> I imagine it does, but I’m seeking confirmation because at the Dublin
> meeting you mentioned you would need check on this.
My idea was that this:
> >
Russ Housley writes:
> I do not think that RFC 9370 changes are the same as the ones we are
> discussing here.
>
> The point has been raised to the Area Directors at this point. I
> will accept whatever they consider best.
I agree with you as a WG chair, and there were others in similar
situatio
Valery Smyslov writes:
> Hi Antony,
> Combining with the proposal above:
>
> Number NameReference
> 0 32-bit Sequential Numbers (SN) [RFC7296] [this ID]
> 1 64-bit Sequential Numbers (ESN) [RFC7296] [this ID]
> 2 32-bit Unspecified
Valery Smyslov writes:
> Hi Tero,
>
> thank you for the initial proposal for the charter. It looks good.
>
> That said I think that not all current charter items are fulfilled.
> While we define how to use PQ KEMs in IKEv2, the issues
> with large keys (beyond 64 Kbytes) are not addressed.
I was
Michael Richardson writes:
> In general, I think that it is overly detailed invokes too much IESG busy
> work, and much of the "current work items" could just be milestones (which
> still requires AD approval). If we went beyond what paragraph two says,
> "... continues the work..." then the AD w
Steffen Klassert writes:
> Hi Tero,
>
> the new charter text covers all our work, so looks good!
>
> On Sat, Nov 16, 2024 at 02:52:13PM +0200, Tero Kivinen wrote:
> >
> > The ESPv3 protocol was defined in 2005 and there has been seen that
> > there might be som
We have now only one item left in our charter (diet-esp and
diet-esp-extension), so it is now time to define new items for the
charter.
Here is my first proposal. I added the items I have heard people have
said they want to work on (and where we already have some drafts out).
If there is any other
Deb Cooley writes:
> Section 4.4.2: Is there a circumstance where distributing both ESP and AH
> policies for the same set of Traffic Selectors would be sensible? If not,
> should this be MUST NOT?
I think this is aligning with the Cryptographic Algorithm
Implementation Requirements and Usage Gu
I want to have confirmation from the authors whether there is any IPRs
known that has not yet been disclosed. Please respond to this email to
confirm this.
Also if anybody else knows any IPRs that has not been already
disclosed, please respond to this email.
There is no currently disclosed IPRs a
Tero Kivinen has requested publication of draft-ietf-ipsecme-g-ikev2-16 as
Proposed Standard on behalf of the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
___
IPsec ma
Antony Antony writes:
> As an extreme example, consider the case where anti-replay protection is
> disabled. Suppose the receiver first receives a packet with sequence number
> 0x0003 0011. Then, it receives an out-of-order packet with sequence
> number 0x FFF0. Although this
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
Here is the agenda for the IPsecME meeting in the IETF #121.
As we will be meeting in the Monday morning, I request all presentors
to send their slides Saturday, so I have time to generate my normal
combined slideset. You can either send slides to chairs directly, or
propose them in the datatracke
Daniel Migault writes:
> We would like to present the two drafts below and believe they will be ready
> for WGLC.
> draft-ietf-ipsecme-diet-esp
> draft-ietf-ipsecme-ikev2-diet-esp-extension
I added 5 minutes for them in the beginning.
--
kivi...@iki.fi
__
Linda Dunbar writes:
> We would like a 10minutes slot at the IPsecme session in IETF 121 to discuss
> this draft:
>
> https://datatracker.ietf.org/doc/draft-dunbar-secdispatch-ligthtweight-authenticate/
>
> This document describes lightweight authentication methods to prevent
> malicious actors t
Send your requests for IPsecME agenda items as soon as possible, so we
can build an agenda for the meeting. Send requests to
ipsecme-cha...@ietf.org.
--
kivi...@iki.fi
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...
While doing my IANA review I found out some comments that might need
fixing in the draft-kampanakis-ml-kem-ikev2-08.
First of all add actual RFC title when refering to them.
It is much more reader friendly to say
To address this concern, Mixing Preshared Keys in IKEv2 [RFC8784]
introduce
Valery Smyslov writes:
> > > In normal IKEv2 each side selects its own IKE SPI, but in
> > > G-IKEv2 it is impossible. It is the GCKS that provides GMs with SPI
> > > for rekey SA and GMs will have to use it to select the right SA.
> >
> > Yes, but as the GM will always only use the first 8 octets
Scott Fluhrer \(sfluhrer\) writes:
> I (and I don’t believe I am alone in this) would like to see an
> ML-KEM RFC for IKE; how can we make it happen?
>
> From what I see, the next step (now that the authors have updated it
> to specify the final version of ML-KEM) would be having it adopted
> by t
Valery Smyslov writes:
> > I did understand that, but I do not see point of sending extra 8-octets as
> the first 8-
> > octets already identifies the IKE SA...
>
> The point is that we want to re-use IKEv2 header, which contains two
> IKE SPIs.
Sure, but this does not have anything to do with th
Valery Smyslov writes:
> > 4.4.1. Group Policies
> >
> > Having terms Group Security Association Policy (GSA Policy) and Group
> > associated Policy (GAP are bit difficult to read, as those two are so
> similar.
> > Perhaps Group Policy (GP) and Group Security Association Policy (GSAP)?
>
> I see
Paul Wouters writes:
> On Fri, Aug 16, 2024 at 10:09 AM Tero Kivinen wrote:
>
> The difference in implementations is minimal, but sending lower
> 32-bits first keeps the ESP backward compatible with different
> firewall, deep packet inspection etc middleboxes, wh
Paul Wouters writes:
> > On the other hand I do think Group 14 is something that most likely
> > needs to be updated...
>
> Yes, some standards like PCI are sun setting finite field DH. The
> question is what to make the new MTI, a NIST curve or a non-NIST
> curve (or both). My guess would be to p
Steffen Klassert writes:
> That said, if we want to transmit the 64-bit sequence number
> in ESP, I'd prefer to transmit the upper 32-bits before
> the lower 32-bits. That's easier on the imlementation side.
The difference in implementations is minimal, but sending lower
32-bits first keeps the ES
Paul Wouters writes:
> I don't believe in this, but if I did, wouldn't you extend the Transorm Type 5
> to:
>
> - SN
> - ESN
> - SN without replay protection
> - ESN without replay protection
>
> Hence my comment about bytes and flags being a bit confusing. I
> don't think we can repurpose this r
Daniel Shiu writes:
> Many thanks for all of the comments. I feel that AUTH_HMAC_SHA1_96
> should be formally deprecated not necessarily for its security*
> relative to the deprecated AUTH_HMAC_SHA1_160, but for purposes of
> consistency, clarity and in support of a broad migration away from
> SHA-
Michael Richardson writes:
> If we are going to rely on the enum alone, then it needs to cover all sorts
> of cases that might be specific to some implementations, while other
> implementations would have a more general code.
Perhaps instead of reason text we have generic enumeration of close
reas
Christian Hopps writes:
> This example doesn't make sense to me, it seems contrived to make
> some point but it's not realistic.
>
> People aren't contacting random IPsec servers that are
> mis-configured for their users. If the user wouldn't understand the
> above language then the operator wou
Valery Smyslov writes:
> I have some comments on draft-pwouters-ipsecme-delete-info that I
> tried to express at IETF120, but due to lack of time they were not
> responded to.
>
> 1. I'm very much concerned with the "Delete Reason Text" field. My
> primary question - in what language this free tex
Valery Smyslov writes:
> The draft uses the method similar to RFC 8784:
>
> SK_d = prf+ (PPK, SK_d')
>
> with the replacement of SK_d with SKEYSEED.
>
> The rationale for using the current form:
> 1. This is the most straightforward and conservative use of prf,
> when the first argument (PP
Valery Smyslov writes:
> The fixed 8 bytes were used for simplicity. The purpose of this field
> is only to avoid use of misconfigured PPKs, so it is believed
> that 2^-64 is an adequate chance for misusing PPK.
> In the worst case the SA won't be established with no clear
> reason in the log file
I finally managed to finish my G-IKEv2 review. Here are my comments:
--
2.3.4. GCKS Registration Operations
The GAP MAY also be
included to provide the ATD and/or DTD (Section 4
This will start two week WGLC for the draft-ietf-ipsecme-ikev2-qr-alt
[1]. This last call will end at 2024-08-11. If you have any comments
about the draft send them to the WG list.
This current draft uses different method of mixing the secret data to
the IKE SA state than the Multiple Key Exchange
Valery Smyslov writes:
> > > In this case additional checks should be performed to make sure that
> > > only PPK_ID formats with confirmation are used for this extension.
> > > It's easier to check this based on the Notify Type, than on PPK_ID
> > > format. The latter is usually performed much deep
Valery Smyslov writes:
> >this extension was being developed, it was a consensus in the IPSECME
> >WG that only IPsec traffic needs to have such a protection. It was
> >believed that no sensitive information is transferred over IKE SA and
> >extending the protection to also cover I
When checking whether this document is ready for WGLC I did quick
review of it. Here are my comments:
--
1. Introduction
...
[RFC8784] defines an IKEv2 extension for protecting
today's IPsec traffic against future quantum
Linda Dunbar writes:
> Could we have a 10-minute slot at the IETF120 IPsecME session to
> present
> https://datatracker.ietf.org/doc/draft-dunbar-secdispatch-ligthtweight-authenticate/
> ?
I was pointed out that you already are in the agenda for alldispatch
and alldispatch wiki says [1]:
ALLDISPA
We might have more time available in the IPsecME next week, when
looking at the number of slides submitted (5/13 slides submitted)...
Send your slides in today before 21:00 Vancouver time.
Fortunately I did mean [1] not [2], otherwise you all would be late
already...
[1] https://en.wikipedia.or
We already have too many presentations that we are going to run out of
time, so most likely we will not be able to go through the whole
agenda, and have to skip some of the presentations in the end.
I want to get slides posted (submitted to datatracker, or sent to the
chairs) before the Saturday e
If you want to present something during IPsecME WG meeting in
Vancouver, send request for agenda time to ipsecme-cha...@ietf.org. I
will try to finish the agenda early next week.
--
kivi...@iki.fi
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe
Shihang(Vincent) writes:
> Hi Tero,
> We moved our draft of IPComp extension from 6man to IPSecMe because
> people told me that IPComp IANA registry is in the IPSec. However
> the extension itself is not related to encryption. I wonder if the
> IPSecMe is the right place for the draft.
It is not,
David Dong via RT writes:
> Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG),
>
> As the designated experts for the IKEv2 Notify Message Types - Error
> Types and Status Types registries, can you review the proposed
> registrations in draft-ietf-ipsecme-multi-sa-performance-06 f
David Dong via RT writes:
> Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG),
>
> As the designated experts for the IKEv2 Notify Message Types -
> Status Types registry, can you review the proposed registration in
> draft-ietf-ipsecme-ikev2-auth-announce-06 for us? Please
Tero Kivinen has requested publication of
draft-ietf-ipsecme-multi-sa-performance-05 as Proposed Standard on behalf of
the IPSECME working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-perfor
I just now noticed that I never announced or marked the result of
adoptionc alls for these two docments, mostly because they expired,
and because that they did not show up in the IPsecME WG document page,
so when I searched all documents in Call for Adoption state, they did
not show up.
Now when D
internet-dra...@ietf.org writes:
> Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now
> available. It is a work item of the IP Security Maintenance and Extensions
> (IPSECME) WG of the IETF.
>
>Title: IKEv2 support for per-resource Child SAs
This seems to cover my comments
Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or
anybody else) aware of any IPRs related to this draft?
Are authors willing to be listed as authors?
I will require response from author, and also updated version of the
draft based on my review comments, before I will hit publicat
In section 1 Introduction:
While this could be (partially) mitigated by setting up multiple
narrowed Child SAs, for example using Populate From Packet (PFP) as
specified in [RFC4301], this IPsec feature is not widely
implemented.
I think it would be better to give better reason why PF
Here is the agenda for the next weeks IPsecME WG. Please submit the
slides to the datatracker before Sunday.
--
IP Security Maintenance and Extensions (IPsecME) WG.
IETF 119 - Tuesday, March 19th, 2024 15:30-17:00
https://meetings
Xialiang\(Frank, IP Security Standard\) writes:
> We have a new draft on IKEv2 support for ShangMi cryptographic algorithm
> suites:
> https://datatracker.ietf.org/doc/draft-guo-ipsecme-ikev2-using-shangmi/.
>
> The main purpose of this draft is to describe how the Chinese mandatory and
> ISO st
If you have anything that you want to be included in the IETF 119
agenda, please send email to the IPsecME WG chairs
(ipsecme-cha...@ietf.org) as soon as possible, as I will be making the
final agenda tomorrow...
--
kivi...@iki.fi
___
IPsec mailing list
Valery Smyslov writes:
> > Ideally, i would even like to see a small section in G-IKEv2 that
> > outlines how GDOI extensions can be mapped to G-IKEv2 . If this
> > waas all registry entries in RFC8052, then it would IMHO even be a
> > great exercise for progressing G-IKEv2 to see if equivalent
> >
Panwei \(William\) writes:
> The handling I suggest is as follows:
>
> 1) if all KE methods proposed by the initiator are unknown to the
> responder, i.e., no KE method is acceptable, then the responder replies
> NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload.
>
>
Paul Wouters writes:
> In RFC 4303 Section 3.3.3 states:
>
> Note: If a receiver chooses to not enable anti-replay for an SA, then
> the receiver SHOULD NOT negotiate ESN in an SA management protocol.
> Use of ESN creates a need for the receiver to manage the anti-replay
> window (
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
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
Michael Pfeiffer writes:
> 1) The main effort for "full" child SAs is not only setting them up,
> but to maintain them (rekeying, monitoring, sending heartbeats and
> the like). In our experience, this becomes especially bad when
> partial failures are possible, i.e., a strict subset of the child
>
Pierre Pfister \(ppfister\) writes:
> "Creating 144 IPsec SA should take less than tenth of a second.
> IKEv2 have windowing mode. With really big systems, creating more
> SAs is not an issue."
>
> We unfortunately cannot afford to throw more cores at every scaling
> issue that we have. IPsec har
This is two week adoption call for
draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting
this document as a working group document for IPsecME to work on, and
then at some point publish this as an RFC, send comments to this list.
This adoption call ends 2023-12-13.
Note, that I do
This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
support adopting this document as a working group document for IPsecME
to work on, and then at some point publish this as an RFC, send
comments to this list.
This adoption call ends 2023-12-13.
Note, that I do want to see peop
This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt.
If you support adopting this document as a working group document for
IPsecME to work on, and then at some point publish this as an RFC,
send comments to this list.
This adoption call ends 2023-12-13.
Note, that I do want to s
1 - 100 of 1057 matches
Mail list logo
