Subject: [IPsec] Cost-efficient quantum-resistant DoS protection

From: Daniel Herzinger <[email-masked]>
Date: Mon, 18 Oct 2021 09:28:47 +0000

Hi,

in response to the new version of draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize the issue of DoS attacks during intermediate exchanges. The new version does address it by mentioning the option of simply avoiding intermediate exchanges altogether but still require additional key exchanges. Yet, this protects only against record-and-harvest attacks but not against an attacker with a strong quantum computer at the time of the handshake, regardless of quantum-resistant authentication (since they can break the initial shared secret and therefore recalculate the MAC which authenticates the followup exchanges, fully establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
An attacker who exploits the large key exchanges, e.g., by requesting seven additional maximum size McEliece key exchanges, can force a gateway to accept and process 1.4MB of data per McEliece KEM. This leaves us at a situation where we must pick one of the following options:

 1. Accept the highly increased risk of DoS attacks.
 2. Prohibit the use of large KE payloads, hence the McEliece mechanism.
 3. Prohibit the use of intermediate exchanges, leaving the IKE SA initially unprotected and being vulnerable to an attacker with a quantum computer during the handshake.

To us, none of these options seems desirable. Thus, we propose another solution which sees one new transform type, e.g., SNTRUP761X25519, which then defines a combination of one classical algorithm (like ECDH based on curve25519) and one pqc algorithm which fits into IKE_SA_INIT without fragmentation (like sntruprime761). The two secrets get concatinated and then fed to a hash function. The resulting hash is used as the shared secret for further key derivation. This mechanism is low effort in terms of implementation and does not affect the state machine at all, but already offers a high level of protection against all attacks as long as there is no major break-through in cryptanalysis. Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For higher long-term security, it can be combined with other, more conventional algorithms which follow either in intermediate or followup exchanges.
We then propose to restrict the use of large key exchanges to the context of option 3, which removes the risk of the described DoS attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519.

The only downside of this approach is that G-IKE is then incompatible with the McEliece exchange. However, the fact that G-IKE exchanges sensitive information before authentication makes it impossible to be not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2.

Regards,

Stefan-Lukas Gazdag, Daniel Herzinger

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Oct 2021 23:50:01 +0300

Daniel Herzinger writes:
> in response to the new version of
> draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize
> the issue of DoS attacks during intermediate exchanges. The new
> version does address it by mentioning the option of simply avoiding
> intermediate exchanges altogether but still require additional key
> exchanges. Yet, this protects only against record-and-harvest
> attacks but not against an attacker with a strong quantum computer
> at the time of the handshake, regardless of quantum-resistant
> authentication (since they can break the initial shared secret and
> therefore recalculate the MAC which authenticates the followup
> exchanges, fully establishing a man-in-the-middle). We doubt that an
> attacker, even with a strong quantum computer, is able to break a
> key exchange in such a short time period. Still, this assumption is
> too theoretical to rely on. This, together with the fact that
> Group-IKE is incompatible with key exchanges during followup
> exchanges, makes the option seem inferior to just sticking to
> intermediate exchanges during the handshake. However, we must also
> consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
>
> An attacker who exploits the large key exchanges, e.g., by
> requesting seven additional maximum size McEliece key exchanges, can
> force a gateway to accept and process 1.4MB of data per McEliece
> KEM. This leaves us at a situation where we must pick one of the
> following options:
> 
>  3. Prohibit the use of intermediate exchanges, leaving the IKE SA
>  initially unprotected and being vulnerable to an attacker with a
>  quantum computer during the handshake.

Not really.

There are several different attacks here and we have different
protection against each of them.

Firstly Diffie-Hellman, Intermediate exchanges etc are not really
meant for DoS protection. 

For DoS protection we have cookies, puzzles (RFC8019), and the fact
that that we know the source IP-address of the attacker (as cookies
forces them to do full round trip before they can do anything else),
and as we know the IP-address(es) we can force puzzles for all unknown
IP-addresses, i.e. anything we have not seen before, and that will
make attackers work much harder. We might allow anybody connecting
from the known IP-addresses without puzzles, just use cookies to force
full round trip, but do puzzles for everybody else.

This does not depend at all whether the attacker has quantum computer
or not (hmm... not sure if our puzzles are faster to calculate on
quantum computer than on normal computer, but at least forcing
attacker to use his quantum computer just to solve our puzzles, might
be a win).

Secondly only authentication type now which is really protected
against quantum computers is the PPK (RFC8784), i.e., post-quantum
preshared keys with strong and random shared secrets. Signatures etc
can be attacked using quantum computer by find out the private key for
them. This might change in the future, but I think that will happen in
general PKIX / X.509 area, i.e., when the certificates can use methods
that are quantum computer safe, we should be able to use them with
just generic signature authentication method (RFC7427).

So now we do IKE_INIT and have Diffie-Hellman done there and attacker
does not even need to have Quantum computer to do attack that as on
path attacker can simply do non-cryptographic attack to stay in the
middle, and see all the traffic going through. This Diffie-Hellman and
all following quantum safe key exchange methods are still
unauthenticated ones.

This means that attacker can force as to do those expensive KE
methods. On the other hand this do require on path attacker, who can
also simply wait for the real initiator to do everything and then
simply block all messages to IKE SA going through the path, thus
severing the IKEv2 connection, can causing reconnection.

It can do that always and there is nothing we can do for that, no
quantum computer needed... And blocking few packets is cheaper than
attacking Diffie-Hellman or even acting as an attacker in the middle.

If you want to protect against doing those quantum safe algorithms
with attacker, you simply do normal childless IKEv2 with just
traditional Diffie-Hellman and use PPK to make sure there is no
attacker in the middle, and after that finishes you rekey that IKEv2
and then do the expensive operations only then. This should give you
full protection of the REKEYed IKEv2 SA, if I have understood the
protocol correctly. 

> To us, none of these options seems desirable. Thus, we propose
> another solution which sees one new transform type, e.g.,
> SNTRUP761X25519, which then defines a combination of one classical
> algorithm (like ECDH based on curve25519) and one pqc algorithm
> which fits into IKE_SA_INIT without fragmentation (like
> sntruprime761). The two secrets get concatinated and then fed to a
> hash function. The resulting hash is used as the shared secret for
> further key derivation.

This does not protect at all against the active on path attacker as it
does not even need to use quantum computer to be able to do that
attack, it simply acts in the middle doing separate connections, one
for the initiator, and another for the responder, and then passes
messages through after decrypting and reencrypting them.

If it has already broken the private key used in the signature to
authenticate the peers, it can successfully stay there after the
authentication (unless PPK was used too).

> This mechanism is low effort in terms of implementation and does not
> affect the state machine at all, but already offers a high level of
> protection against all attacks as long as there is no major
> break-through in cryptanalysis.

It does not affect the state machine, but it does affect the crypto
calculations which has quite big impact on the protocol.

On the other hand as this is just new Key Exchange algorithm, there is
actually no need to change IKEv2 at all, as long as that new KE simply
generates one shared secret (g^ir) that can be used on both ends,
i.e., the combining of the separate secrets happens inside the key
exchange algorithm not in the IKEv2 protocol.

I myself think this is wasted effort, as it does not provide us any
protection against active attackers (except that attacker need to
implement that new algorithm too :-), and doing those algorithms as
separate steps is easier and more modularized.

> Furthermore, it is the accepted approach for most of the
> applications of post-quantum key exchanges. For higher long-term
> security, it can be combined with other, more conventional
> algorithms which follow either in intermediate or followup
> exchanges.
>
> We then propose to restrict the use of large key exchanges to the
> context of option 3, which removes the risk of the described DoS
> attacks. Yet, to prevent the insecurities of plain option 3, we also
> propose to make it mandatory to combine it with the new hybrid
> transform type, i.e., SNTRUP761X25519.

Restricting algorithms is completely up to the policy you use. Even
when using IKE_INTERMEDIATE exchange you can do so that you first do
classical Diffie-Hellman, then do cheap quantum safe algorithm (like
the sntruprime761 you mentioned) and then do the authentication in the
IKE_AUTH using PPK, and after that do IKE SA rekey and during that you
do the more expensive methods that were not allowed by policy
earlier..

> The only downside of this approach is that G-IKE is then
> incompatible with the McEliece exchange. However, the fact that
> G-IKE exchanges sensitive information before authentication makes it
> impossible to be not vulnerable against the discussed DoS attack
> and, at the same time, support the McEliece algorithm. Thus, we see
> that as a decision to be made in the G-IKE standardization track,
> not in IKEv2.

I do not think G-IKEv2 needs to exchange any sensitive information
during the GSA_AUTH. In the GSA_AUTH SAg is optional, GSA, and KD are
optional, only think that is mandatory is the IDg, which is identical
to IDi, and IDr, i.e., indicates identity. We might want to make sure
GSA_AUTH can use PPK as described in the RFC8784, i.e., mention
N(USE_PPK) for IKE_SA_INIT and add optional N(PPK_IDENTITY, PPK_ID) to
GSA_AUTH.

We have already talked earlier that if we want to have proper identity
protection against all attackers we need to use pseudonym method,
i.e., the IDi (and IDg) would be pseudonym for the device, not the
real identity. Then the IKEv2 does IKE SA rekey to create channel
which is protected against all attackers when using PPK, and after
that it can do pseudonym maintenance.

In the simplist case the server simply sends client few dozen one use
random unique pseudonyms that the client can use next time it connects
over that channel. And next time when it connects the server updates
new pseudonyms for future use etc.

Also I think G-IKEv2 is written in a way where it should allow
IKE_INTERMEDIATE exchanges between the IKE_SA_INIT and GSA_AUTH, but I
have not verified whether there is something still missing there.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Oct 2021 18:45:35 +0300

Hi Daniel and Stefan-Lukas,

> Hi,
> 
> in response to the new version of draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize the
> issue of DoS attacks during intermediate exchanges. The new version does address it by mentioning the
> option of simply avoiding intermediate exchanges altogether but still require additional key exchanges. Yet,
> this protects only against record-and-harvest attacks but not against an attacker with a strong quantum
> computer at the time of the handshake, regardless of quantum-resistant authentication (since they can break
> the initial shared secret and therefore recalculate the MAC which authenticates the followup exchanges, fully
> establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is able
> to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. This,
> together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, makes
> the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we must
> also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
> An attacker who exploits the large key exchanges, e.g., by requesting seven additional maximum size McEliece
> key exchanges, can force a gateway to accept and process 1.4MB of data per McEliece KEM. 

Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods MUST be different.
Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will.
This is not true. First peers negotiate which key exchanges they will perform (including additional key exchanges),
and you can limit the types and the number additional key exchanges the responder will accept via its local policy.

> This leaves us at
> a situation where we must pick one of the following options:
> 
>  3. Prohibit the use of intermediate exchanges, leaving the IKE SA initially unprotected and being vulnerable to
> an attacker with a quantum computer during the handshake.
> 
> To us, none of these options seems desirable. Thus, we propose another solution which sees one new
> transform type, e.g., SNTRUP761X25519, which then defines a combination of one classical algorithm (like

I'm confused here - did you mean new transform type or new transform ID?
Transform types define a kind of algorithms (or other features, like ESN), while 
transform IDs define a particular algorithm of this type.

Unless I'm missing something I presume you meant new transform ID which
defines a new key exchange algorithm which is a combination of SNTRUP761 and X25519.
Correct me if I'm wrong.

> ECDH based on curve25519) and one pqc algorithm which fits into IKE_SA_INIT without fragmentation (like
> sntruprime761). The two secrets get concatinated and then fed to a hash function. The resulting hash is used
> as the shared secret for further key derivation. This mechanism is low effort in terms of implementation and
> does not affect the state machine at all, but already offers a high level of protection against all attacks as long
> as there is no major break-through in cryptanalysis. Furthermore, it is the accepted approach for most of the
> applications of post-quantum key exchanges. For higher long-term security, it can be combined with other,
> more conventional algorithms which follow either in intermediate or followup exchanges.

I think that this combined key exchange algorithm can also be implemented (with more flexibility)
by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach
has real advantages in terms of consuming responder's resources. The responder still needs to 
perform both X25519 and SNTRUP761 before it authenticates the initiator.
Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles 
are roughly the same. I'd like also mention that while X25519 and SNTRUP761 public
keys are fit into a single 1500 bytes IKE message, they leave relatively little space
for SA payload, so initiator may be limited in expressing its proposals.

> We then propose to restrict the use of large key exchanges to the context of option 3, which removes the risk
> of the described DoS attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it
> mandatory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519.

Are you proposing to stick with these two particular algorithms?
I don't think it's a good idea, giving the algorithm agility requirements.
I think that the same result can be achieved with the current draft:

IKE_SA_INIT(X25519 or whatever else)
IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key)
IKE_AUTH(Childless if you want)
CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key)

This leaves much more flexibility in selecting particular algorithms.

> The only downside of this approach is that G-IKE is then incompatible with the McEliece exchange. However,
> the fact that G-IKE exchanges sensitive information before authentication makes it impossible to be not
> vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. Thus, we
> see that as a decision to be made in the G-IKE standardization track, not in IKEv2.

I agree that G-IKEv2 is very special, but I also agree with Tero's previous message
that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves in slightly different area.
We have some mechanisms for this (not perfect, but that is that).

Regards,
Valery.

---

From: "Kampanakis, Panos" <[email-masked]>
Date: Thu, 21 Oct 2021 15:49:02 +0000

Hi Valery, Tero, 

Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will.
This is not true. First peers negotiate which key exchanges they will perform (including additional key exchanges), and you can limit the types and the number additional key exchanges the responder will accept via its local policy.

I think the point is valid though if the responder supports McEliece. A miscreant can that way make the responder put a lot of data on the wire like an amplification attack although the initiator has not been validated. QUIC has a 3x amplification protection limits for that matter. 

Sure, the issue existed even in ECDH exchanges, but the impact is much higher when we talk MB of public keys. 

Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too many packets mean pretty high loss probability in unstable networks which means pretty bad performance unless everything happens in the datacenter or robust end-to-end network paths. The PQ KEMs that will end up being standardized are likely to have just a few KBs of public key and ciphertext which is better for the general case. 

So, I would say option 3 (prohibit the use of very large KE payloads like McEliece's MB sized public keys) is more practical. 

Rgs,
Panos

-----Original Message-----
From: IPsec <[email-masked]> On Behalf Of Valery Smyslov
Sent: Tuesday, October 19, 2021 11:46 AM
To: 'Daniel Herzinger' <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protection

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

> exchanges. Yet, this protects only against record-and-harvest attacks 
> but not against an attacker with a strong quantum computer at the time 
> of the handshake, regardless of quantum-resistant authentication 
> (since they can break the initial shared secret and therefore 
> recalculate the MAC which authenticates the followup exchanges, fully 
> establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
> An attacker who exploits the large key exchanges, e.g., by requesting 
> seven additional maximum size McEliece key exchanges, can force a gateway to accept and process 1.4MB of data per McEliece KEM.

Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods MUST be different.
Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will.
This is not true. First peers negotiate which key exchanges they will perform (including additional key exchanges), and you can limit the types and the number additional key exchanges the responder will accept via its local policy.

> initially unprotected and being vulnerable to an attacker with a quantum computer during the handshake.
>
> To us, none of these options seems desirable. Thus, we propose another 
> solution which sees one new transform type, e.g., SNTRUP761X25519, 
> which then defines a combination of one classical algorithm (like

I'm confused here - did you mean new transform type or new transform ID?
Transform types define a kind of algorithms (or other features, like ESN), while transform IDs define a particular algorithm of this type.

Unless I'm missing something I presume you meant new transform ID which defines a new key exchange algorithm which is a combination of SNTRUP761 and X25519.
Correct me if I'm wrong.

> ECDH based on curve25519) and one pqc algorithm which fits into 
> IKE_SA_INIT without fragmentation (like sntruprime761). The two 
> secrets get concatinated and then fed to a hash function. The 
> resulting hash is used as the shared secret for further key 
> derivation. This mechanism is low effort in terms of implementation 
> and does not affect the state machine at all, but already offers a 
> high level of protection against all attacks as long as there is no major break-through in cryptanalysis. Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For higher long-term security, it can be combined with other, more conventional algorithms which follow either in intermediate or followup exchanges.

I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in terms of consuming responder's resources. The responder still needs to perform both X25519 and SNTRUP761 before it authenticates the initiator.
Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in expressing its proposals.

> attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519.

IKE_SA_INIT(X25519 or whatever else)
IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key)

> The only downside of this approach is that G-IKE is then incompatible 
> with the McEliece exchange. However, the fact that G-IKE exchanges 
> sensitive information before authentication makes it impossible to be 
> not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2.

I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves in slightly different area.
We have some mechanisms for this (not perfect, but that is that).

Regards,
Valery.

> Stefan-Lukas Gazdag, Daniel Herzinger

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: CJ Tjhai <[email-masked]>
Date: Thu, 21 Oct 2021 17:39:16 +0100

Hi Panos,

There are two drafts involved here.

a) the main draft,
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/,
cannot support any public-key larger than 64KB, so it can never be used for
KEMs like McEliece. So the option 3 is implied here.

b) on the other hand,
https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an
attempt to address the issue with transferring payload larger than 64KB. As
you pointed out, transferring large blob of data in a live protocol is
challenging and therefore it deservers separate treatments and
considerations. It was deliberate that we split the hybrid key exchange
drafts into two, the second draft is there just in case there is any
interest in the working group on supporting the use KEMs like McEliece.

Cheers,
CJ

On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos <kpanos=
[email-masked]> wrote:

> Hi Valery, Tero,
>
> > Not really. First, the situation with seven McEliece is not possible,
> since all negotiated Key Exchange methods MUST be different.
> This is not true. First peers negotiate which key exchanges they will
> perform (including additional key exchanges), and you can limit the types
> and the number additional key exchanges the responder will accept via its
> local policy.
>
> I think the point is valid though if the responder supports McEliece. A
> miscreant can that way make the responder put a lot of data on the wire
> like an amplification attack although the initiator has not been validated.
> QUIC has a 3x amplification protection limits for that matter.
>
> Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too
> many packets mean pretty high loss probability in unstable networks which
> means pretty bad performance unless everything happens in the datacenter or
> robust end-to-end network paths. The PQ KEMs that will end up being
> standardized are likely to have just a few KBs of public key and ciphertext
> which is better for the general case.
>
> So, I would say option 3 (prohibit the use of very large KE payloads like
> McEliece's MB sized public keys) is more practical.
>
> Rgs,
> Panos
>
>
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> > establishing a man-in-the-middle). We doubt that an attacker, even with
> a strong quantum computer, is able to break a key exchange in such a short
> time period. Still, this assumption is too theoretical to rely on. This,
> together with the fact that Group-IKE is incompatible with key exchanges
> during followup exchanges, makes the option seem inferior to just sticking
> to intermediate exchanges during the handshake. However, we must also
> > seven additional maximum size McEliece key exchanges, can force a
> gateway to accept and process 1.4MB of data per McEliece KEM.
>
> Not really. First, the situation with seven McEliece is not possible,
> since all negotiated Key Exchange methods MUST be different.
> This is not true. First peers negotiate which key exchanges they will
> perform (including additional key exchanges), and you can limit the types
> and the number additional key exchanges the responder will accept via its
> local policy.
>
> > This leaves us at
> Transform types define a kind of algorithms (or other features, like ESN),
> while transform IDs define a particular algorithm of this type.
>
> > high level of protection against all attacks as long as there is no
> major break-through in cryptanalysis. Furthermore, it is the accepted
> approach for most of the applications of post-quantum key exchanges. For
> higher long-term security, it can be combined with other, more conventional
> algorithms which follow either in intermediate or followup exchanges.
>
> I think that this combined key exchange algorithm can also be implemented
> (with more flexibility) by doing
> IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your
> approach has real advantages in terms of consuming responder's resources.
> The responder still needs to perform both X25519 and SNTRUP761 before it
> authenticates the initiator.
> Yes, you save one round trip, but the amount of data sent on the wire and
> the amount of CPU cycles are roughly the same. I'd like also mention that
> while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE
> message, they leave relatively little space for SA payload, so initiator
> may be limited in expressing its proposals.
>
> propose to make it mandatory to combine it with the new hybrid transform
> type, i.e., SNTRUP761X25519.
>
> IKE_AUTH(Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or
> whatever else with long public key)
>
> > not vulnerable against the discussed DoS attack and, at the same time,
> support the McEliece algorithm. Thus, we see that as a decision to be made
> in the G-IKE standardization track, not in IKEv2.
>
> I agree that G-IKEv2 is very special, but I also agree with Tero's
> previous message that protecting IKEv2 and (G-IKEv2 too) against DoS
> attacks leaves in slightly different area.

-- 

PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited 
company incorporated in England and Wales with registered number 06808505.

This email is meant only for the intended recipient. If you have received 
this email in error, any review, use, dissemination, distribution, or 
copying of this email is strictly prohibited. Please notify us immediately 
of the error by return email and please delete this message from your 
system. Thank you in advance for your cooperation.

For more information 
about Post-Quantum, please visit www.post-quantum.com 
<http://www.post-quantum.com>.

In the course of our business relationship, 
we may collect, store and transfer information about you. Please see our 
privacy notice at www.post-quantum.com/privacy-notice 
<http://www.post-quantum.com/privacy-notice> to learn about how we use this 
information.

---

From: Daniel Herzinger <[email-masked]>
Date: Tue, 26 Oct 2021 12:25:37 +0000

Hi,

the fact is that accepting a significantly increased amount of data from an unauthenticated peer also significantly increases the surface to DoS attacks. Even without surpassing the 64KB limit, this must be a concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. Now, an attacker must still accept these costs but can use one connection to trigger several key exchanges, all significantly larger than what we had with DH, making the trade-off way better for them compared to non-pqc IKEv2. So, the attacker could, e.g., negotiate several FrodoKEMs (all with different parameters to circumvent the rule that all key exchange methods must be different). Compared to classical non-hybrid (EC)DH, such a DoS attack requires significantly less cost to have the same effect.
The introduction of MB-sized key exchanges just amplifies this problem even further (also allowing several McEliece KEMs with different parameters circumventing this constraint). Thus, while we should already thoroughly asses and mitigate the risk of this possible weakness for https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/.
Currently, there is no place defined where a McEliece-sized key exchange can take place. So, at least one of the two drafts (probably beyond-64k or multiple-ke) or better both should make this clear. At the moment, beyond-64k defines how the transmission of such key exchanges could look like but the question of where these ideas could be put into action are left to the reader, leading to inevitable confusion. The fact that there are several drafts aiming at the same problem, without really defining their contact points or interactions, further exacerbates this.

The most obvious way to prevent an attacker from exploiting the new attack surface is to accept the larger key exchanges only from an already authenticated peer. As mentioned before, we think childless IKEv2 with immediate rekeying would be a good compromise to achieve that.

> Imo, McEliece is not practical for live protocols like TLS or IKEv2.
McEliece is more trusted than its pqc alternatives which also makes it the favored choice of some agencies like the German BSI. Obviously, they all know the challenges of integrating such large key exchanges, still they would surely appreciate any effort which goes into this direction. This justifies pursuing the idea further, especially since first measurements look better than one would probably expect.
To give more insight about these measurements, we implemented all three drafts and tested the performance of a medium-sized McEliece key exchange under different networking conditions (variable latency, packet loss, and throughput). Especially when packet loss or throughput surpass specific threshholds (~ above 1% packet loss and below 3Mbit of throughput), the overall performance suffers significantly. Yet, we deem those values acceptable, as long as we don't use cellular or similarly unreliable networks. Furthermore, we expect a gateway communicating with many peers to have higher requirements to its network uplink. Yet, as this will most likely be positioned in a data center, this challenge should also be doable. Altogether, this left us with a surprisingly positive view on the possibility of adopting McEliece-sized key exchanges at least for some use-cases.

The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-term solution, as it addresses the problem without requiring much effort in terms of standardization or implementation. This becomes even more important, as intermediate exchanges and their high complexity, due to their interconnectedness with authentication, mean that especially the IKEv2 implementations of smaller projects will take their time for its integration. Thus, having an easier short-term solution at hand means a real advantage.
Also, the constrained size of such transforms mostly eliminates the aforementioned DoS risks.
Finally, should the beyond-64k draft be adopted, then having a small set of such additional Tranform-IDs is even more beneficial since it makes preventing the unlikely yet possible attack described in our initial mail easier.

Regards,
Stefan and Daniel
________________________________________
Von: CJ Tjhai <[email-masked]>
Gesendet: Donnerstag, 21. Oktober 2021 18:39:16
An: Kampanakis, Panos
Cc: Valery Smyslov; Daniel Herzinger; [email-masked]; [email-masked]
Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection

Hi Panos,

a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot support any public-key larger than 64KB, so it can never be used for KEMs like McEliece. So the option 3 is implied here.

b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an attempt to address the issue with transferring payload larger than 64KB. As you pointed out, transferring large blob of data in a live protocol is challenging and therefore it deservers separate treatments and considerations. It was deliberate that we split the hybrid key exchange drafts into two, the second draft is there just in case there is any interest in the working group on supporting the use KEMs like McEliece.

Cheers,
CJ

On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos <kpanos=[email-masked]<mailto:[email-masked]>> wrote:
Hi Valery, Tero,

Rgs,
Panos

-----Original Message-----
From: IPsec <[email-masked]<mailto:[email-masked]>> On Behalf Of Valery Smyslov
Sent: Tuesday, October 19, 2021 11:46 AM
To: 'Daniel Herzinger' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protection

Regards,
Valery.

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

________________________________
PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company incorporated in England and Wales with registered number 06808505.

This email is meant only for the intended recipient. If you have received this email in error, any review, use, dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the error by return email and please delete this message from your system. Thank you in advance for your cooperation.

For more information about Post-Quantum, please visit www.post-quantum.com<http://www.post-quantum.com>.

In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy notice at www.post-quantum.com/privacy-notice<http://www.post-quantum.com/privacy-notice> to learn about how we use this information.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Oct 2021 11:35:06 +0300

Hi Stefan, Daniel,

> Hi,
> 
> the fact is that accepting a significantly increased amount of data from an unauthenticated peer also
> significantly increases the surface to DoS attacks. Even without surpassing the 64KB limit, this must be a
> concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection.
> Now, an attacker must still accept these costs but can use one connection to trigger several key exchanges, all
> significantly larger than what we had with DH, making the trade-off way better for them compared to non-pqc
> IKEv2. So, the attacker could, e.g., negotiate several FrodoKEMs (all with different parameters to circumvent
> the rule that all key exchange methods must be different). Compared to classical non-hybrid (EC)DH, such a
> DoS attack requires significantly less cost to have the same effect.
> The introduction of MB-sized key exchanges just amplifies this problem even further (also allowing several
> McEliece KEMs with different parameters circumventing this constraint). 

As I've already said, the responder is free to limit the types and the number of key exchanges it is willing to accept
from unauthenticated initiator.

> Thus, while we should already
> thoroughly asses and mitigate the risk of this possible weakness for https://datatracker.ietf.org/doc/draft-
> ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-
> beyond-64k-limit/.
> Currently, there is no place defined where a McEliece-sized key exchange can take place. So, at least one of
> the two drafts (probably beyond-64k or multiple-ke) or better both should make this clear. At the moment,
> beyond-64k defines how the transmission of such key exchanges could look like but the question of where
> these ideas could be put into action are left to the reader, leading to inevitable confusion. The fact that there
> are several drafts aiming at the same problem, without really defining their contact points or interactions,
> further exacerbates this.

Sorry, I failed to understand why you think there is no contact points or interactions. 
Actually, beyond-64k is using multiple-ke and only defines how we can overcome 64KB payload size limit.

> The most obvious way to prevent an attacker from exploiting the new attack surface is to accept the larger
> key exchanges only from an already authenticated peer. As mentioned before, we think childless IKEv2 with
> immediate rekeying would be a good compromise to achieve that.

This is one possible solution. I don't think we should make it the only one.
And I think this scenario is already described in multiple-ke.

> McEliece is more trusted than its pqc alternatives which also makes it the favored choice of some agencies like
> the German BSI. Obviously, they all know the challenges of integrating such large key exchanges, still they
> would surely appreciate any effort which goes into this direction. This justifies pursuing the idea further,
> especially since first measurements look better than one would probably expect.
> To give more insight about these measurements, we implemented all three drafts and tested the performance
> of a medium-sized McEliece key exchange under different networking conditions (variable latency, packet loss,
> and throughput). Especially when packet loss or throughput surpass specific threshholds (~ above 1% packet
> loss and below 3Mbit of throughput), the overall performance suffers significantly. Yet, we deem those values
> acceptable, as long as we don't use cellular or similarly unreliable networks. Furthermore, we expect a
> gateway communicating with many peers to have higher requirements to its network uplink. Yet, as this will
> most likely be positioned in a data center, this challenge should also be doable. Altogether, this left us with a
> surprisingly positive view on the possibility of adopting McEliece-sized key exchanges at least for some use-
> cases.

In cases when the packet loss is high it is possible to use mixed transport mode, defined in beyond-64K.

> The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-term solution, as it addresses
> the problem without requiring much effort in terms of standardization or implementation. This becomes even
> more important, as intermediate exchanges and their high complexity, due to their interconnectedness with
> authentication, mean that especially the IKEv2 implementations of smaller projects will take their time for its
> integration. Thus, having an easier short-term solution at hand means a real advantage.

I think that defining new Transform-IDs like SNTRUP761X25519 is orthogonal to multiple-ke and beyond-64K.
There are some advantages in using this combined key exchange mode, there are some disadvantages too.
For example, the agility property is degraded, since you cannot negotiate which hash function to use
when shared secrets are combined (well, this can be solved if you simply concatenate them, but 
it is a question for cryptographers how to do it right).

> Finally, should the beyond-64k draft be adopted, then having a small set of such additional Tranform-IDs is
> even more beneficial since it makes preventing the unlikely yet possible attack described in our initial mail
> easier.

In my opinion you can also get most of the advantages by using IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761) instead.
Well, in this case you have to implement IKE_INTERMEDITE (which you seem to think is too complex)
and you have to do additional round trip. On the other hand, you are more flexible in 
choosing which classic and PQ KE methods to combine and how (e.g. you can also do
IKE_SA_INIT(SNTRUP761)+IKE_INTERMEDIATE(X25519)).

Regards,
Valery.

> a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot support any
> public-key larger than 64KB, so it can never be used for KEMs like McEliece. So the option 3 is implied here.
> 
> b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an attempt to
> address the issue with transferring payload larger than 64KB. As you pointed out, transferring large blob of
> data in a live protocol is challenging and therefore it deservers separate treatments and considerations. It was
> deliberate that we split the hybrid key exchange drafts into two, the second draft is there just in case there is
> any interest in the working group on supporting the use KEMs like McEliece.
> 
> Cheers,
> CJ
> 
> 
> 
> 
> On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos
> <kpanos=[email-masked]<mailto:[email-masked]>> wrote:
> Hi Valery, Tero,
> 
> This is not true. First peers negotiate which key exchanges they will perform (including additional key
> exchanges), and you can limit the types and the number additional key exchanges the responder will accept
> via its local policy.
> 
> I think the point is valid though if the responder supports McEliece. A miscreant can that way make the
> responder put a lot of data on the wire like an amplification attack although the initiator has not been
> validated. QUIC has a 3x amplification protection limits for that matter.
> 
> Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too many packets mean pretty high loss
> probability in unstable networks which means pretty bad performance unless everything happens in the
> datacenter or robust end-to-end network paths. The PQ KEMs that will end up being standardized are likely to
> have just a few KBs of public key and ciphertext which is better for the general case.
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments
> unless you can confirm the sender and know the content is safe.
> 
> 
> 
> > establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is
> able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on.
> This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges,
> makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we
> must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
> This is not true. First peers negotiate which key exchanges they will perform (including additional key
> exchanges), and you can limit the types and the number additional key exchanges the responder will accept
> via its local policy.
> 
> > This leaves us at
> Unless I'm missing something I presume you meant new transform ID which defines a new key exchange
> algorithm which is a combination of SNTRUP761 and X25519.
> Correct me if I'm wrong.
> 
> > high level of protection against all attacks as long as there is no major break-through in cryptanalysis.
> Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For
> higher long-term security, it can be combined with other, more conventional algorithms which follow either in
> intermediate or followup exchanges.
> 
> I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing
> IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in
> terms of consuming responder's resources. The responder still needs to perform both X25519 and
> SNTRUP761 before it authenticates the initiator.
> Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are
> roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single
> 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in
> expressing its proposals.
> 
> > attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine
> it with the new hybrid transform type, i.e., SNTRUP761X25519.
> 
> IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want)
> > not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm.
> Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2.
> 
> I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and
> (G-IKEv2 too) against DoS attacks leaves in slightly different area.
> PQ Solutions Limited (trading as 'Post-Quantum') is a private limited company incorporated in England and
> Wales with registered number 06808505.
> 
> This email is meant only for the intended recipient. If you have received this email in error, any review, use,
> dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the
> error by return email and please delete this message from your system. Thank you in advance for your
> cooperation.
> 
> In the course of our business relationship, we may collect, store and transfer information about you. Please
> see our privacy notice at www.post-quantum.com/privacy-notice<http://www.post-quantum.com/privacy-
> notice> to learn about how we use this information.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 29 Oct 2021 22:37:39 +0300

Daniel Herzinger writes:
> the fact is that accepting a significantly increased amount of data
> from an unauthenticated peer also significantly increases the
> surface to DoS attacks.

Accepting data is not a DoS attack problem.

If the other end sends you lots of packets, you will have to cope with
that, there is nothing you can do to limit it sending you data.

Sending data back is where we might get DoS amplification factor, but
what the amplification factor is depends on the size of packets
initiator sends you and what is size of packets you send back.

With normal Diffie-Hellman those both are same, so there is no
amplification factor.

Also amplification factor is really important only when you can do it
as (D)DoS attack against third party. I.e., you use source attack of
the intended victim on your message and send the message to some real
server on the network who will send bigger reply back to the victim,
not to the attacker. If the attacker can send small packet and get
much bigger packet back then he gains amplification and he is better
of using this kind of reflected attack instead of sending packets to
victim himself.

Of course if he can use lots of reflectors on the network he can do
even better, i.e., make a DDoS attack...

In IKEv2 this is only possible with the IKE_SA_INIT, because all later
packets do require you to be on the path to see the response packets
from the server to victim to be able to continue exchange.

In the IKEv2 we do have protection against that, so the responders
IKE_SA_INIT response is usually smaller than the request from the
initiator. The SA payload will be either same or smaller, nonce
payloads can be bit different lengths, but they are limited to 64
bytes, KE payloads are of same size, optional CERTREQ from the server
is usually only few hashes thus few tens of bytes. Also the initiator
usually adds several notify payloads and responder only reflects back
those it supports.

And if responder decideds to send back cookie request, to verify the
source address of the initiator, then the response packet is much
smaller.

> Even without surpassing the 64KB limit, this must be a concern.
> IKEv2's cookie mechanism and puzzles try to increase the cost of the
> attacker per each connection. Now, an attacker must still accept
> these costs but can use one connection to trigger several key
> exchanges, all significantly larger than what we had with DH, making
> the trade-off way better for them compared to non-pqc IKEv2.

No it cannot. Attacker can use cookie only once, and will only get one
exchange created by each cookie exchange, thus it needs to do puzzles
and cookies again for every single attack packet it wants to send.

Immediately when he sends the packet after the IKE_SA_INIT (i.e.,
IKE_AUTH or IKE_INTERMEDIATE) the SPIi is consumed, thus if he tries
to send another IKE_AUTH/IKE_INTERMEDIATE with same SPIi the responder
will assume it is just retransmission of the previous
IKE_AUTH/IKE_INTERMEDIATE (if it is identical than last time) and then
it will retransmit its response from last time. If the attacker
modifies the IKE_AUTH/IKE_INTERMEDIATE request it sends, the initiator
will ignore it as it is not retransmission and it is not valid message
to the existing IKE SA.

And to be able to send valid IKE_AUTH/IKE_INTERMEDIATE that will cause
any action on the initiator will again require the attacker to be on
path i.e., be somewhere where it can see the IKE_SA_INIT response the
initiator sent, thus attacker in a position where it can do much more
harm than simple DoS using reflection attack.

So I do not think DoS attack properties of the IKEv2 is at all
modified with addition to the multiple ke, or beyond 64k limit drafts.

> So, the attacker could, e.g., negotiate several FrodoKEMs (all with
> different parameters to circumvent the rule that all key exchange
> methods must be different). Compared to classical non-hybrid (EC)DH,
> such a DoS attack requires significantly less cost to have the same
> effect.

Why should the responder accept such proposal? What benefits is there
to do multiple FrodoKEMs with different parameters in normal case?

I would assume responder would simply pick one of the FrodoKEMs with
the parameters that match its security requirements, and only use
that, and if initiator does not offer a way to pick only one, the
initiator will rejecte the whole proposal.

The SAi and SAr exchange in the IKE_SA_INIT is a agreement protocol
where initiator proposes list of algorithms, and responder picks
suitable (sub)set of algorithms. Initiator of course only proposes
algorithms that are acceptable for him based on his security policy,
and responder will only pick algorithm sets which are acceptable for
his security policy.

> The introduction of MB-sized key exchanges just amplifies this
> problem even further (also allowing several McEliece KEMs with
> different parameters circumventing this constraint).

I would assume most implementors do consider the constraint that each
KEM must be different in a such way that parameters are not considered
at all. I.e., even if you propose McEliece with multiple parameter
sets, implementation will check its policy whether McEliece is
acceptable, and if so then pick one of the parameter sets that match
their security needs, and do not consider McEliece anymore for later
rounds, i.e., it would not allow multiple McEliece with different
parameter sets, because draft says you do not do same KEM multiple
times. 

> Thus, while we
> should already thoroughly asses and mitigate the risk of this
> possible weakness for
> we definitely must do it for
> https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/.

Actually I do not think it belongs to them, it belongs to whatever
draft that defines McEliece to be used with those two.

Tha draft should note that there are issues using large keys in IKEv2,
and most likely it should say SHOULD NOT do that using
IKE_INTERMEDIATE, and only use the large keys after the IKE SA has
been authenticated.

> Currently, there is no place defined where a McEliece-sized key
> exchange can take place. So, at least one of the two drafts
> (probably beyond-64k or multiple-ke) or better both should make this
> clear. At the moment, beyond-64k defines how the transmission of
> such key exchanges could look like but the question of where these
> ideas could be put into action are left to the reader, leading to
> inevitable confusion. The fact that there are several drafts aiming
> at the same problem, without really defining their contact points or
> interactions, further exacerbates this.

We do not have draft at all for McEliece where this kind of discussion
belongs. 

> The most obvious way to prevent an attacker from exploiting the new
> attack surface is to accept the larger key exchanges only from an
> already authenticated peer. As mentioned before, we think childless
> IKEv2 with immediate rekeying would be a good compromise to achieve
> that.

McEliece draft should most likely have strong recommendation to do
just that. 

> The introduction of new Transform-IDs like SNTRUP761X25519 is a good
> short-term solution, as it addresses the problem without requiring
> much effort in terms of standardization or implementation.

I think IKE_INTERMEDIATE is better solution, and you doing normal
X25519 in IKE_SA_INIT and then SNTRUP761 in IKE_INTERMEDIATE will
solve the issue with just one extra round trip, and still keep the
IKE_SA_INIT packet small enough that it does not get fragmented (i.e.,
less than 1280). 

> This becomes even more important, as intermediate exchanges and
> their high complexity, due to their interconnectedness with
> authentication, mean that especially the IKEv2 implementations of
> smaller projects will take their time for its integration. Thus,
> having an easier short-term solution at hand means a real advantage.

I do not think implementing IKE_INTERMEDIATE is that hard, especially
if you limit yourself to just very limited subset of algorithms you
support. 

> aforementioned DoS risks.

I do not think there are any new DoS risks, so there is no need to
eliminate them....
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 15:04:57 -0400

> and cookies again for every single attack packet it wants to send.

I wonder if anyone has any stats on how often cookie challenge is used, how
often puzzles are invoked.

    > modified with addition to the multiple ke, or beyond 64k limit drafts.

I agree.

IKEv2 is not SSLv3.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Graham Bartlett <[email-masked]>
Date: Sun, 31 Oct 2021 21:38:07 +0000

Hi

I'm not aware of any IKEv2 implementations that use puzzles.

I probably see cookies enabled in maybe 5% to 10% of deployments. On Cisco,
the cookie can be enabled if X number of 1/2 open sessions are seen, hence
it might not be active unless there is either some anomaly in the network
(GW reboot and all clients connecting at the same time), or DoS attack
(never seen in real life).

cheers