Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-10-12 Thread Mirja Kuehlewind (IETF)
Hi Valery,

okay. Didn’t see that it’s already in the RFC editor queue. 

One more comment below but no big issue. So everything you do is fine.

> Am 12.10.2016 um 16:22 schrieb Valery Smyslov :
> 
> Hi Mirja,
> 
> please see inline. The draft is already in RFC Editor's queue, so please
> see our reasonings for addressing your comments (we add one clarifications
> and ignored two other cases, please see why).
> 
> Regards,
> Valery.
> 
>> Hi Valery,
>> 
>> sorry for the late reply (holidays :-) )
>> 
>> See below.
>> 
>> On 25.09.2016 22:20, Valery Smyslov wrote:
>>> Hi Mirja, Yoav,
>>> 
>>> I agree with Yoav's answers, just want to clarify a few things. See below
>>> (I removed the comments where I have nothing to add to Yoav's answers).
>>> 
> --
> COMMENT:
> --
> 
> Some questions:
> 
> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
> should ignore it and try to send reply without the puzzle solution, as
> there might be still a change to get served…? If it then received another
> packet with puzzle it can still solve it and reply.
 
 A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the 
 regular payloads like SA is invalid according
 to RFC 7296.
 That is one reason why we chose to keep the COOKIE notification and add a 
 PUZZLE notification rather than put both
 pieces of
 data in the new notification. A response with only PUZZLE and no COOKIE is 
 invalid and should be treated as such.
 So after some (not specified anywhere) time, the Initiator should start a 
 new IKE_SA_INIT exchange, hoping that this
 time the
 Responder returns a valid response.
>>> 
>>> Actually, the Initiator sends requests, not responses. So, if the Initiator 
>>> ignores
>>> invalid response from the Responder, then the only thing it can do is to 
>>> wait
>>> some time and sends another request (or just retransmit the sent request in 
>>> hope
>>> that invalid response was from an attacker who wants to break IKE SA 
>>> establishment).
>>> If the situation doesn't improve (the Initiator continues to receive 
>>> invalid responses),
>>> then the Initator has nothing to do but give up.
>>> 
>>> I just want to emphasise that Mirja's suggestion (ignore invalid response) 
>>> is exactly
>>> what the draft suggests to do in this case, as Yoav correctly outlined. 
>>> Isn't it clear enough from the
>>> document? Should we add more clarifications?
>> 
>> I guess add one sentence stating this explicitly cant hurt?
> 
> I think the draft is very clear:
> 
>  In this case the
>  Initiator MUST ignore the received message and continue to wait until
>  either a valid PUZZLE notification is received or the retransmission
>  timer fires.  If it fails to receive a valid message after several
>  retransmissions of IKE_SA_INIT requests, then it means that something
>  is wrong and the IKE SA cannot be established.
> 
> This text is completely in line with RFC7296 (Section 2.21.1):
> 
>  Because all error notifications are completely
>  unauthenticated, the recipient should continue trying for some time
>  before giving up.  The recipient should not immediately act based on
>  the error notification unless corrective actions are defined in this
>  specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
>  INVALID_MAJOR_VERSION.
> 
> They both tell that the Initiator must not act immediately on receiving
> malformed packet or error notification in IKE_SA_INIT since this
> packets are unauthenticated. Instead, the Initiator must try to
> get a valid response by retransmitting the request for some time
> and give up only if no valid response is received.
> 
> So, I frankly don't see how we can improve the text. If you have
> the text you think is really important to add, then please provide it.
> 
> 3) also sec 7.1.4: Does the following sentence really makes sense? How
> doe the responser know? Maybe just remove it?
> „The more time the Initiator spent solving the puzzles, the higher
> priority it should receive.“
 
 The Responder cannot know. It can only assume based on the expected number 
 of steps in finding a solution with a
 certain number of trailing zero bits.
>>> 
>>> The Responder can also measure the time between the puzzle request and
>>> the reception of puzzle solution (and the Responder can do this in a 
>>> stateless manner).
>>> Sure this measurment cannot be accurate, because it includes RTT, but it
>>> can be used as additional input to the prioritizing algorithm (along
>>> with puzzle difficulty and the number of times the puzzle was requested).
>>> But in general the prioritizing algorithm is a local matter of Responder
>>> and the draft doesn't mandatae it in any way.
>> 
>> In this case I would recommend a 

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-10-12 Thread Valery Smyslov

Hi Mirja,

please see inline. The draft is already in RFC Editor's queue, so please
see our reasonings for addressing your comments (we add one clarifications
and ignored two other cases, please see why).

Regards,
Valery.


Hi Valery,

sorry for the late reply (holidays :-) )

See below.

On 25.09.2016 22:20, Valery Smyslov wrote:

Hi Mirja, Yoav,

I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).


--
COMMENT:
--

Some questions:

1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
should ignore it and try to send reply without the puzzle solution, as
there might be still a change to get served…? If it then received another
packet with puzzle it can still solve it and reply.


A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular 
payloads like SA is invalid according
to RFC 7296.
That is one reason why we chose to keep the COOKIE notification and add a 
PUZZLE notification rather than put both
pieces of
data in the new notification. A response with only PUZZLE and no COOKIE is 
invalid and should be treated as such.
So after some (not specified anywhere) time, the Initiator should start a new 
IKE_SA_INIT exchange, hoping that this
time the
Responder returns a valid response.


Actually, the Initiator sends requests, not responses. So, if the Initiator 
ignores
invalid response from the Responder, then the only thing it can do is to wait
some time and sends another request (or just retransmit the sent request in hope
that invalid response was from an attacker who wants to break IKE SA 
establishment).
If the situation doesn't improve (the Initiator continues to receive invalid 
responses),
then the Initator has nothing to do but give up.

I just want to emphasise that Mirja's suggestion (ignore invalid response) is 
exactly
what the draft suggests to do in this case, as Yoav correctly outlined. Isn't 
it clear enough from the
document? Should we add more clarifications?


I guess add one sentence stating this explicitly cant hurt?


I think the draft is very clear:

  In this case the
  Initiator MUST ignore the received message and continue to wait until
  either a valid PUZZLE notification is received or the retransmission
  timer fires.  If it fails to receive a valid message after several
  retransmissions of IKE_SA_INIT requests, then it means that something
  is wrong and the IKE SA cannot be established.

This text is completely in line with RFC7296 (Section 2.21.1):

  Because all error notifications are completely
  unauthenticated, the recipient should continue trying for some time
  before giving up.  The recipient should not immediately act based on
  the error notification unless corrective actions are defined in this
  specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
  INVALID_MAJOR_VERSION.

They both tell that the Initiator must not act immediately on receiving
malformed packet or error notification in IKE_SA_INIT since this
packets are unauthenticated. Instead, the Initiator must try to
get a valid response by retransmitting the request for some time
and give up only if no valid response is received.

So, I frankly don't see how we can improve the text. If you have
the text you think is really important to add, then please provide it.


3) also sec 7.1.4: Does the following sentence really makes sense? How
doe the responser know? Maybe just remove it?
„The more time the Initiator spent solving the puzzles, the higher
priority it should receive.“


The Responder cannot know. It can only assume based on the expected number of 
steps in finding a solution with a
certain number of trailing zero bits.


The Responder can also measure the time between the puzzle request and
the reception of puzzle solution (and the Responder can do this in a stateless 
manner).
Sure this measurment cannot be accurate, because it includes RTT, but it
can be used as additional input to the prioritizing algorithm (along
with puzzle difficulty and the number of times the puzzle was requested).
But in general the prioritizing algorithm is a local matter of Responder
and the draft doesn't mandatae it in any way.


In this case I would recommend a short warning that if the response time is measured as an estimated for the 
processing time, network delay should be taken into account.


The Responder has no reliable means to separate RTT
from the time the Initiator spent for solving the puzzle.
The Responder can only suggest that if, for example, the puzzle solution
was returned in 10 seconds, then it probably took ~9 seconds for solving
the puzzle and ~1 second for network delay. But it could happen that
network quality is poor and in reality the figures are just opposite.
Since the Responder cannot reliably "distill" CPU consumption 

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-10-12 Thread Mirja Kühlewind

Hi Valery,

sorry for the late reply (holidays :-) )

See below.

On 25.09.2016 22:20, Valery Smyslov wrote:

Hi Mirja, Yoav,

I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).


--
COMMENT:
--

Some questions:

1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
should ignore it and try to send reply without the puzzle solution, as
there might be still a change to get served…? If it then received another
packet with puzzle it can still solve it and reply.


A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular 
payloads like SA is invalid according
to RFC 7296.
That is one reason why we chose to keep the COOKIE notification and add a 
PUZZLE notification rather than put both
pieces of
data in the new notification. A response with only PUZZLE and no COOKIE is 
invalid and should be treated as such.
So after some (not specified anywhere) time, the Initiator should start a new 
IKE_SA_INIT exchange, hoping that this
time the
Responder returns a valid response.


Actually, the Initiator sends requests, not responses. So, if the Initiator 
ignores
invalid response from the Responder, then the only thing it can do is to wait
some time and sends another request (or just retransmit the sent request in hope
that invalid response was from an attacker who wants to break IKE SA 
establishment).
If the situation doesn't improve (the Initiator continues to receive invalid 
responses),
then the Initator has nothing to do but give up.

I just want to emphasise that Mirja's suggestion (ignore invalid response) is 
exactly
what the draft suggests to do in this case, as Yoav correctly outlined. Isn't 
it clear enough from the
document? Should we add more clarifications?


I guess add one sentence stating this explicitly cant hurt?




3) also sec 7.1.4: Does the following sentence really makes sense? How
doe the responser know? Maybe just remove it?
„The more time the Initiator spent solving the puzzles, the higher
priority it should receive.“


The Responder cannot know. It can only assume based on the expected number of 
steps in finding a solution with a
certain number of trailing zero bits.


The Responder can also measure the time between the puzzle request and
the reception of puzzle solution (and the Responder can do this in a stateless 
manner).
Sure this measurment cannot be accurate, because it includes RTT, but it
can be used as additional input to the prioritizing algorithm (along
with puzzle difficulty and the number of times the puzzle was requested).
But in general the prioritizing algorithm is a local matter of Responder
and the draft doesn't mandatae it in any way.


In this case I would recommend a short warning that if the response time is 
measured as an estimated for the processing time, network delay should be 
taken into account.





5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
PUZZLE notification and the Initiator supports puzzles, it MUST solve the
puzzle.“
Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“?
Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
notification…“)


Sure. Seems to be a typo.


No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH 
exchange
cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH 
request
(that is sent by the Initiator), the puzzle must be given to the Initiator 
earlier,
i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT 
response.
So the text is correct.

However, I understand Mirja's source of confusion - in IKEv2 there are
three different kinds of IKE_SA_INIT responses ("regular", COOKIE and
INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct
names - they all are IKE_SA_INIT response. So, there is no contradiction with
7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE 
request
(and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response,
i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case
the Initiator can ignore puzzle request (if PUZZLE is present in a response 
containing COOKIE)
and still have a chance to be served, in the second case it cannot ignore 
puzzle request
(when PUZZLE is present in a "regular" IKE_SA_INIT response).

Do you think it is not clear enough and more clarifications are needed?


If it's possible to clarify this without data to much text about RFC7296 that 
would clearly help!


Thanks,
Mirja





Regards,
Valery.



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-09-25 Thread Valery Smyslov

Hi Mirja, Yoav,

I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).


> --
> COMMENT:
> --
>
> Some questions:
>
> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
> should ignore it and try to send reply without the puzzle solution, as
> there might be still a change to get served…? If it then received another
> packet with puzzle it can still solve it and reply.

A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according 
to RFC 7296.
That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both 
pieces of

data in the new notification. A response with only PUZZLE and no COOKIE is 
invalid and should be treated as such.
So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this 
time the

Responder returns a valid response.


Actually, the Initiator sends requests, not responses. So, if the Initiator 
ignores
invalid response from the Responder, then the only thing it can do is to wait
some time and sends another request (or just retransmit the sent request in hope
that invalid response was from an attacker who wants to break IKE SA 
establishment).
If the situation doesn't improve (the Initiator continues to receive invalid 
responses),
then the Initator has nothing to do but give up.

I just want to emphasise that Mirja's suggestion (ignore invalid response) is 
exactly
what the draft suggests to do in this case, as Yoav correctly outlined. Isn't 
it clear enough from the
document? Should we add more clarifications?


> 3) also sec 7.1.4: Does the following sentence really makes sense? How
> doe the responser know? Maybe just remove it?
> „The more time the Initiator spent solving the puzzles, the higher
> priority it should receive.“

The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a 
certain number of trailing zero bits.


The Responder can also measure the time between the puzzle request and
the reception of puzzle solution (and the Responder can do this in a stateless 
manner).
Sure this measurment cannot be accurate, because it includes RTT, but it
can be used as additional input to the prioritizing algorithm (along
with puzzle difficulty and the number of times the puzzle was requested).
But in general the prioritizing algorithm is a local matter of Responder
and the draft doesn't mandatae it in any way.


> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
> PUZZLE notification and the Initiator supports puzzles, it MUST solve the
> puzzle.“
> Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“?
> Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
> notification…“)

Sure. Seems to be a typo.


No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH 
exchange
cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH 
request
(that is sent by the Initiator), the puzzle must be given to the Initiator 
earlier,
i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT 
response.
So the text is correct.

However, I understand Mirja's source of confusion - in IKEv2 there are
three different kinds of IKE_SA_INIT responses ("regular", COOKIE and
INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct
names - they all are IKE_SA_INIT response. So, there is no contradiction with
7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE 
request
(and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response,
i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case
the Initiator can ignore puzzle request (if PUZZLE is present in a response 
containing COOKIE)
and still have a chance to be served, in the second case it cannot ignore 
puzzle request
(when PUZZLE is present in a "regular" IKE_SA_INIT response).

Do you think it is not clear enough and more clarifications are needed?

Regards,
Valery. 


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-09-23 Thread Mirja Kuehlewind (IETF)
Hi Yoav,

okay. I guess some of the reasoning you gave could go into the draft…

Thanks!
Mirja


> Am 23.09.2016 um 22:06 schrieb Yoav Nir :
> 
> Hi.
> 
> See responses below
> 
>> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind  wrote:
> 
>> --
>> COMMENT:
>> --
>> 
>> Some questions:
>> 
>> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
>> should ignore it and try to send reply without the puzzle solution, as
>> there might be still a change to get served…? If it then received another
>> packet with puzzle it can still solve it and reply.
> 
> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the 
> regular payloads like SA is invalid according to RFC 7296. That is one reason 
> why we chose to keep the COOKIE notification and add a PUZZLE notification 
> rather than put both pieces of data in the new notification. A response with 
> only PUZZLE and no COOKIE is invalid and should be treated as such. So after 
> some (not specified anywhere) time, the Initiator should start a new 
> IKE_SA_INIT exchange, hoping that this time the Responder returns a valid 
> response.
> 
>> 
>> 2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe
>> there are cases where the burden for the initiator is high enough by
>> requesting the solution that there is already an effect even if the
>> responder decides to not verify it…? 
> 
> There was a suggestion discussed that the Responder MAY choose not to check 
> the solution or randomly check just one of the four solutions. The WG didn’t 
> like that as it makes the protocol non-deterministic and makes things harder 
> to test. So consensus was to make the verification mandatory. Of course, this 
> doesn’t affect interoperability, so we can’t force a responder to check 
> everything.
> 
>> 3) also sec 7.1.4: Does the following sentence really makes sense? How
>> doe the responser know? Maybe just remove it?
>>  „The more time the Initiator spent solving the puzzles, the higher
>> priority it should receive.“
> 
> The Responder cannot know. It can only assume based on the expected number of 
> steps in finding a solution with a certain number of trailing zero bits.
> 
>> 4) sec 7.2.1.1 says „the Responder would be able to estimate the
>> computational power of the Initiator and select the difficulty level
>> accordingly.“ How would it estimate the computational power? Based on the
>> reply time? Wouldn’t it also need to know the RTT and current congestion
>> level then?
> 
> The only estimate that the responder has is based on what the initiator 
> solved during the IKE_SA_INIT exchange. If the Initiator solved a level-15 
> puzzle (15 trailing zeros in each of the four solutions) then it stands to 
> reason that it *can* solve a level-15 puzzle. Maybe the word “estimate” is 
> misleading here.
> 
>> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
>> PUZZLE notification and the Initiator supports puzzles, it MUST solve the
>> puzzle.“
>>  Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? 
>>  Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
>> notification…“)
> 
> Sure. Seems to be a typo.
> 
>> Two general comments/questions:
>> 
>> 1) What’s about the additional cpu load of the responder to calculate the
>> puzzle. Can that be a problem? Are there any strategies to keep that low
>> (recalculation/caching/reuse)? How long should things be cached/used?
>> Maybe add a few sentences in the Operational Considerations section!
> 
> Verifying a puzzle solution involves 4 invocation of a MAC function on a few 
> tens of bytes. This is very low considering that (1) IKE initiation involves 
> at least one and typically two PK operations, and (2) IKE is for generating 
> key material which is then used to MAC millions or billions of packets.
> 
>> 2) Would it make sense to also give a field to change the number of
>> requested keys to scale load? Or why was it decided to use a fixed number
>> of 4 here?
> 
> You scale the load by changing the difficulty (number of requested trailing 
> zero bits).  The reason we are asking for 4 solutions rather than 1 is to 
> make the amount of work more predictable. We could make it even more 
> predictable with 16 solutions, but that makes the packet bigger and runs the 
> risk of requiring packet fragmentation. So we chose 4 as a reasonable 
> compromise.  See this mail about it:
> https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A
> 
> Yoav
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

2016-09-23 Thread Yoav Nir
Hi.

See responses below

> On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind  wrote:

> --
> COMMENT:
> --
> 
> Some questions:
> 
> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
> should ignore it and try to send reply without the puzzle solution, as
> there might be still a change to get served…? If it then received another
> packet with puzzle it can still solve it and reply.

A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular 
payloads like SA is invalid according to RFC 7296. That is one reason why we 
chose to keep the COOKIE notification and add a PUZZLE notification rather than 
put both pieces of data in the new notification. A response with only PUZZLE 
and no COOKIE is invalid and should be treated as such. So after some (not 
specified anywhere) time, the Initiator should start a new IKE_SA_INIT 
exchange, hoping that this time the Responder returns a valid response.

> 
> 2) sec 7.1.4: Does „the Responder MUST verify the puzzle solution“? Maybe
> there are cases where the burden for the initiator is high enough by
> requesting the solution that there is already an effect even if the
> responder decides to not verify it…? 

There was a suggestion discussed that the Responder MAY choose not to check the 
solution or randomly check just one of the four solutions. The WG didn’t like 
that as it makes the protocol non-deterministic and makes things harder to 
test. So consensus was to make the verification mandatory. Of course, this 
doesn’t affect interoperability, so we can’t force a responder to check 
everything.

> 3) also sec 7.1.4: Does the following sentence really makes sense? How
> doe the responser know? Maybe just remove it?
>   „The more time the Initiator spent solving the puzzles, the higher
> priority it should receive.“

The Responder cannot know. It can only assume based on the expected number of 
steps in finding a solution with a certain number of trailing zero bits.

> 4) sec 7.2.1.1 says „the Responder would be able to estimate the
> computational power of the Initiator and select the difficulty level
> accordingly.“ How would it estimate the computational power? Based on the
> reply time? Wouldn’t it also need to know the RTT and current congestion
> level then?

The only estimate that the responder has is based on what the initiator solved 
during the IKE_SA_INIT exchange. If the Initiator solved a level-15 puzzle (15 
trailing zeros in each of the four solutions) then it stands to reason that it 
*can* solve a level-15 puzzle. Maybe the word “estimate” is misleading here.

> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
> PUZZLE notification and the Initiator supports puzzles, it MUST solve the
> puzzle.“
>   Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? 
>   Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
> notification…“)

Sure. Seems to be a typo.

> Two general comments/questions:
> 
> 1) What’s about the additional cpu load of the responder to calculate the
> puzzle. Can that be a problem? Are there any strategies to keep that low
> (recalculation/caching/reuse)? How long should things be cached/used?
> Maybe add a few sentences in the Operational Considerations section!

Verifying a puzzle solution involves 4 invocation of a MAC function on a few 
tens of bytes. This is very low considering that (1) IKE initiation involves at 
least one and typically two PK operations, and (2) IKE is for generating key 
material which is then used to MAC millions or billions of packets.

> 2) Would it make sense to also give a field to change the number of
> requested keys to scale load? Or why was it decided to use a fixed number
> of 4 here?

You scale the load by changing the difficulty (number of requested trailing 
zero bits).  The reason we are asking for 4 solutions rather than 1 is to make 
the amount of work more predictable. We could make it even more predictable 
with 16 solutions, but that makes the packet bigger and runs the risk of 
requiring packet fragmentation. So we chose 4 as a reasonable compromise.  See 
this mail about it:
https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A

Yoav

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec