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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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 <[e-mail]>:
> 
> 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 time,
> I think this warning wouldn't help implementers. The time spent for solving a puzzle
> 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…

Mirja

> 
>>>>> 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!
> 
> We've added a clarification in 7.2.2 that regular IKE_SA_INIT response is meant
> (containing SA, KE, NONCE etc. payloads).
> 
> 
>> Thanks,
>> Mirja
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Valery.
>