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 <sva...@gmail.com>:
> 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).
>> 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).
>>>>> 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
>>> invalid response from the Responder, then the only thing it can do is to
>>> some time and sends another request (or just retransmit the sent request in
>>> that invalid response was from an attacker who wants to break IKE SA
>>> 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
> 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 time,
> I think this warning wouldn't help implementers. The time spent for solving a
> is just an additional input data for Responder's decision, but definitely
> not the primary one, which is the puzzle's difficulty.
I agree. If there is no RTT estimate available at all, I would actually rather
recommend to not use the response time at all and remove this sentence. However
not a big issue anyway. What I meant by a warning is to explicitly say that
this information might no be super useful as the network delay is not known…
>>>>> 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
>>>>> 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
>>>> Sure. Seems to be a typo.
>>> No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH
>>> cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH
>>> (that is sent by the Initiator), the puzzle must be given to the Initiator
>>> i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT
>>> 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
>>> 7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE
>>> (and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT
>>> 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!
> We've added a clarification in 7.2.2 that regular IKE_SA_INIT response is
> (containing SA, KE, NONCE etc. payloads).
IPsec mailing list