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 <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). > > 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. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec