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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.