Re: Issue 26: Window size and latest_update_counter (was: Comments on draft-ietf-mobike-protocol-00.txt)
"Mohan Parthasarathy" <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <00b201c58757$828f6fb0$6501a8c0@adithya> |
The text looks fine to me. -mohan ----- Original Message ----- From: <[email protected]> To: <[email protected]>; <[email protected]> Sent: Tuesday, July 12, 2005 3:28 AM Subject: Issue 26: Window size and latest_update_counter (was: Comments on draft-ietf-mobike-protocol-00.txt) Mohan Parthasarathy wrote: > -Section 2.3: > > - Does not explain, what happens when the "window size does > not allow ? It retransmits the existing message with the new > address and responder sends back to the new address but > without updating the SAs ? This is sort of implicit in the > text because the SAs are updated with the new address pair in > the first step and any retransmissions will happen with the > new address. Yes, it keeps retransmitting the outstanding requests using the addresses in the IKE_SA (=the new addresses). I'll add something about this in -01... > - What is "latest_update_received" counter ? Where else is it > used other than this step? Either the counter is updated or > not. It is not clear what this counter is used for as it just > appears in this step alone. It's not used anywhere else except in this step. The purpose of the counter is to ensure correct behavior if the responder receives several address update requests out of order: it should follow the newest update, and ignore older ones (except that a reply needs to be sent anyway). (Receiving requests out of order can of course only happen with window size greater than 1). But I agree, the text could be clearer. How about changing this o Compares the Message ID with the latest_update_received counter in the IKE_SA. If latest_update_received is greater than the received Message ID, the reply is sent as usual, but no other action is taken; otherwise, updates the latest_update_received counter. to this? o Determines whether it has already received a newer CHANGE_PATH request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a response message is sent, but no other action is taken. Best regards, Pasi