On Fri, 28 Oct 2022, Guillaume Solignac (gsoligna) wrote:
Is this requirement only based on not reusing the same IV on different cores or
is there an additional factor I missed?
For AES-GCM there is a 2^32 max operations per private key as well.
Are you referring to NIST SP 800-38D § 8.3 ? T
Hi Tero,
> Question is how many CPUs do you need to saturate 100 Gbit/s network
> link compared to how many HSM CPUs you need? is there more than 10
> times bigger number between them.
I think it depends on both CPUs and HSMs :-) And on algorithm too.
For example, AES has implemented in most mode
Valery Smyslov writes:
> > There is no point of one having for example 10 fast cpus sending
> > traffic over 10 Child SA, when the receiving end only has two cpus
> > which are about same than the other ends cpus. The receiving end will
> > not be able to keep up with the traffic it is getting in,
Paul Ponchon \(pponchon\) writes:
> > > Using different real child SA’s was needed to ensure the
> > > cryptographic security properties.
>
> Is this requirement only based on not reusing the same IV on different cores
> or is there an additional factor I missed?
IV space and replay counter are t
Paul,
> > Is this requirement only based on not reusing the same IV on different
> > cores or is there an additional factor I missed?
> For AES-GCM there is a 2^32 max operations per private key as well.
Are you referring to NIST SP 800-38D § 8.3 ? This is the closest I could find
to this restr
HI Tero,
> In your discussion you were talking about cases where one device has
> hundreds of cpus and other have few. Only case where such
> configurations would be useful when other has lots of really low
> powered cpus and other one has few very fast ones. My understanding is
> that this is not
On Oct 27, 2022, at 08:40, Paul Ponchon (pponchon)
wrote:
>
>
>
> Is this requirement only based on not reusing the same IV on different cores
> or is there an additional factor I missed?
For AES-GCM there is a 2^32 max operations per private key as well.
>
> We're are currently facing s
Hi,
Tero Kivinen writes:
> [Replying to this email, but commenting about the others also]
>
> Paul Wouters writes:
> > On Oct 21, 2022, at 03:37, Steffen Klassert
> > mailto:steffen.klass...@secunet.com>> wrote:
> > > Another possibility would be to use the same keymat on all
> > > percpu SAs
> >
[Replying to this email, but commenting about the others also]
Paul Wouters writes:
> On Oct 21, 2022, at 03:37, Steffen Klassert
> wrote:
> > Another possibility would be to use the same keymat on all
> > percpu SAs
>
> You cannot do that. You need to ensure unique IVs for AEAD so you
> would
Hi Valery,
On Fri, Oct 21, 2022 at 05:06:44PM +0300, Valery Smyslov wrote:
> >
> > The percpu SAs don't need locking as long as you can make sure that
> > it is never ever accessed by a remote cpu. To guarantee this, something
> > that does the 'dirt work' is needed. In our case that would be the
Hi Steffen,
> Hi Valery,
>
> > Then my next question is - how the sending side decides
> > whether to one of use per-CPU SAs or the fallback SA?
> > My guess that the packet is handled by some kernel thread
> > (i.e. by some CPU), so once this CPU figures out that
> > it doesn't have an SA - I as
On Oct 21, 2022, at 03:37, Steffen Klassert
wrote:
>
>
> Another possibility would be to use the same keymat on all
> percpu SAs
You cannot do that. You need to ensure unique IVs for AEAD so you would need to
subdivide the IV space. You would also still reach max operations on these SAs
on
Hi Valery,
On Mon, Oct 17, 2022 at 05:10:32PM +0300, Valery Smyslov wrote:
> > >
> > > > I could guess that the fallback SA *does* require locks.
> > >
> > > It also seems to me. So I see no difference if the packet
> > > can be re-steered to a different CPU, in any case we'll have
> > > performan
Hi Paul,
> On Wed, 19 Oct 2022, Valery Smyslov wrote:
>
> >> Requesting to install 1 million Child SA's until the remote server falls
> >> over.
> >> Perhaps less extremely, to contain the number of resources a sysadmin
> >> allocates to a specific "multi CPU" tunnel.
> >
> > I still fail to und
On Wed, 19 Oct 2022, Valery Smyslov wrote:
Requesting to install 1 million Child SA's until the remote server falls over.
Perhaps less extremely, to contain the number of resources a sysadmin
allocates to a specific "multi CPU" tunnel.
I still fail to understand how this protection mechanism w
Hi Paul,
> On Tue, 18 Oct 2022, Valery Smyslov wrote:
>
> >>> implementation with say 10 CPUs. Does it make any difference for this
> >>> implementation
> >>> If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in
> >>> both cases
> >>> it will follow its own local policy for l
Hi Paul,
> On Tue, 18 Oct 2022, Valery Smyslov wrote:
>
> >> I think this is implementation specific. You could install an temporary
> >> rule into the SPD that would give the fallback SA more priority than the
> >> per-CPU policy installed, so it wouldn't generate ACQUIRES for a while.
> >
> > W
On Tue, 18 Oct 2022, Valery Smyslov wrote:
implementation with say 10 CPUs. Does it make any difference for this
implementation
If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in both
cases
it will follow its own local policy for limiting the number of per-CPU SAs,
most pr
On Tue, 18 Oct 2022, Valery Smyslov wrote:
I think this is implementation specific. You could install an temporary
rule into the SPD that would give the fallback SA more priority than the
per-CPU policy installed, so it wouldn't generate ACQUIRES for a while.
Why for a while? And for how long?
Hi Paul,
> On Mon, 17 Oct 2022, Valery Smyslov wrote:
>
> > implementation with say 10 CPUs. Does it make any difference for this
> > implementation
> > If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in
> > both cases
> > it will follow its own local policy for limiting th
Hi Paul,
> On Mon, 17 Oct 2022, Valery Smyslov wrote:
>
> [leaving cache/linux implementation details to Steffen to answer]
>
> > Another issue that is not clear from the draft -
> > how per-CPU SAs are created. Consider the situation when
> > an outgoing packet is handled by a CPU
> > and there
On Mon, 17 Oct 2022, Valery Smyslov wrote:
implementation with say 10 CPUs. Does it make any difference for this
implementation
If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in both
cases
it will follow its own local policy for limiting the number of per-CPU SAs,
most pr
I think that the point is that even if there are n CPUs, that a sensibly
designed system might well have n+1 SAs active.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
On Mon, 17 Oct 2022, Valery Smyslov wrote:
[leaving cache/linux implementation details to Steffen to answer]
Another issue that is not clear from the draft -
how per-CPU SAs are created. Consider the situation when
an outgoing packet is handled by a CPU
and there is no per-CPU Sa to handle it.
Hi Steffen,
[snipped]
> > My main problem with the draft is the concept of "Fallback SA". This SA is
> > treated specially in the draft,
> > which I don't think is necessary. For example, it must always be up so that
> > the outgoing packet can
> > always be sent in case per-CPU SA does not exi
Hi Steffen,
> > > Valery Smyslov wrote:
> > > > My main problem with the draft is the concept of "Fallback SA".
> > > This SA
> > > > is treated specially in the draft, which I don't think is
> > > > necessary. For example, it must always be up so that the outgoing
> > > > packet
Hi Valery,
thanks for yor feedback! Some comments inline.
On Tue, Oct 11, 2022 at 05:37:29PM +0300, Valery Smyslov wrote:
> Hi all,
>
> as I promised at the last IETF meeting, this is my review of the
> draft-pwouters-ipsecme-multi-sa-performance draft.
> This is not a formal review of the docu
Hi,
On Tue, Oct 11, 2022 at 07:14:32PM +0300, Valery Smyslov wrote:
> Hi Michael,
>
> > Valery Smyslov wrote:
> > > My main problem with the draft is the concept of "Fallback SA". This
> > SA
> > > is treated specially in the draft, which I don't think is
> > > necessary. For exampl
Hi Michael,
> Valery Smyslov wrote:
> > My main problem with the draft is the concept of "Fallback SA". This SA
> > is treated specially in the draft, which I don't think is
> > necessary. For example, it must always be up so that the outgoing
> > packet can always be sent in case
Valery Smyslov wrote:
> My main problem with the draft is the concept of "Fallback SA". This SA
> is treated specially in the draft, which I don't think is
> necessary. For example, it must always be up so that the outgoing
> packet can always be sent in case per-CPU SA does not e
30 matches
Mail list logo
