Hi Pierre,
On Mon, Dec 04, 2023 at 08:52:52AM +, Pierre Pfister (ppfister) wrote:
> Hi all,
>
>
>
> I'd like to encourage a discussion here around why the solution described in
> draft-ponchon-ipsecme-anti-replay-subspaces is needed, and why
> draft-ietf-ipsecme-multi-sa-performance is no
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
On Thu, Dec 07, 2023 at 06:47:35PM -0500, Paul Wouters wrote:
> On Thu, 7 Dec 2023, Michael Rossberg wrote:
>
> > > > I would actually like to refrain from writing 2 * 1.024 keys from the
> > > > control
> > > > plane to the data plane, just because a single IKE SA rekeyed...
> > >
> > > If you
On Thu, Dec 07, 2023 at 04:43:44PM +0100, Michael Rossberg wrote:
> Hi Paul,
>
> >> My understanding is that when PFS is enabled, the first CHILD_SA leverages
> >> the IKE SA key, but any further CREATE_CHILD_SA (which is the case when
> >> setting up more “sub-SAs”) would use separate keys.
> >>
On Thu, 7 Dec 2023, Michael Rossberg wrote:
I would actually like to refrain from writing 2 * 1.024 keys from the control
plane to the data plane, just because a single IKE SA rekeyed...
If you rekey the IKE SA, there is no change to the Child SA's. The new
IKE SA inherits the existing Child S
> -Original Message-
> From: IPsec On Behalf Of Michael Rossberg
> Sent: Thursday, December 7, 2023 12:14 PM
> To: Paul Wouters
> Cc: Pierre Pfister (ppfister) ;
> ipsec@ietf.org
> Subject: Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
>
>
&g
>> I would actually like to refrain from writing 2 * 1.024 keys from the control
>> plane to the data plane, just because a single IKE SA rekeyed...
>
> If you rekey the IKE SA, there is no change to the Child SA's. The new
> IKE SA inherits the existing Child SAs. So no 2 * 1024 new keys.
May b
On Thu, 7 Dec 2023, Michael Rossberg wrote:
I would actually like to refrain from writing 2 * 1.024 keys from the control
plane to the data plane, just because a single IKE SA rekeyed...
If you rekey the IKE SA, there is no change to the Child SA's. The new
IKE SA inherits the existing Child S
Hi Paul,
>> My understanding is that when PFS is enabled, the first CHILD_SA leverages
>> the IKE SA key, but any further CREATE_CHILD_SA (which is the case when
>> setting up more “sub-SAs”) would use separate keys.
>> >From RFC5996:
>> Although ESP and AH do not directly include a Diffie-Hellm
On Thu, 7 Dec 2023, Pierre Pfister (ppfister) wrote:
My understanding is that when PFS is enabled, the first CHILD_SA leverages
the IKE SA key, but any further CREATE_CHILD_SA (which is the case when
setting up more “sub-SAs”) would use separate keys.
>From RFC5996:
Although ESP and AH do
Hello Paul, thank for the reply,
> It's not really an issue of cores. You do not need to do that many DH
> exchanges, and those are the only real expensive operation.
> As Tero explained, to get PFS on many Child SAs, you create an IKE SA,
> then create thousands of tunnels without PFS, and then
Hello Tero, thanks for the reply.
> > "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 h
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
>
Hi,
On Mon, 2023-12-04 at 08:52 +, Pierre Pfister (ppfister) wrote:
>
> So far, we have received feedback from people supporting our work, and
> sharing the same need. I'd like to encourage those people to take part in
> this thread.
>
basically, I can only reiterate the arguments we have a
On Mon, 4 Dec 2023, Pierre Pfister (ppfister) wrote:
We have received pushbacks from Tero. But I am curious to know if other people
share the same opinion, or not.
I think I do. At least, I see a use case for this, but I don't see it
based on your current explanations.
To bootstrap the conv
On Mon, 4 Dec 2023, Ben Schwartz wrote:
As I've mentioned previously, I think this draft is valuable for
"network-to-network" tunneling, where the sender and receiver are
both represented by a large (and evolving) collection of gateways (perhaps
sharing IPs via anycast).
I don't understand w
As I've mentioned previously, I think this draft is valuable for
"network-to-network" tunneling, where the sender and receiver are both
represented by a large (and evolving) collection of gateways (perhaps sharing
IPs via anycast). This situation requires O(N^2) SAs in the current protocol,
bu
18 matches
Mail list logo
