Mohan Parthasarathy | 6 Apr 02:41 2005

Re: issue 11 -- window size


Some questions/clarifications..

> Now if we want to see why we cannot modify the packet between
> retranmissions take the next case where we have also shorter temporary
> failures or one way connections.
> Connection between A1 and B2 breaks down (A1 address does not work).
> Host A notices that he hasn't received anything and starts DPD.
> (A1, B2, 57) DPD -> (dropped)
> (A1, B2, 57) DPD -> (dropped)
> (A1, B2, 57) DPD -> (dropped)
> Host A notices that he is not getting anything back so he starts
> searching for the working address pair:
> (A2, B1, 57) DPD ->
> Host B gets the packet, and replies to it, but the
> packet is dropped because of some other reason (one
> way path etc). Host B has now calculated HASH(DPD) and
> stored it in his incoming window for message id 57,
> and also has stored the "DPD reply" to be sent back in
> case the message id 57 (HASH(DPD)) is retranmitted.
> (drop) <- (B1, A2, 57R) DPD reply
> Host A retransmits
> (A2, B1, 57) DPD ->
> Host B gets retramission of 57, he verifies that it is
> retranmission by checking the HASH(DPD), and because
> it matches, he sends stored copy of message id 57R
> back, without doing any more processing for the
The receiver needs to do a HASH to detect the change.
Today the receiver on receiving the above message, just
 sends the stored response out as he knows it is a retransmission
 by just looking at the Message-id. 

> packet (i.e. he does not run any IKE state machines to
> process the packet). 
> (drop) <- (B1, A2, 57R) DPD reply
> Host A moves to next address and retransmits
> (A3, B1, 57) DPD ->
> Host B again notices about retranmission, and replies
> with his stored packet.
When the host detects the HASH change, he notes down
*just* the new addresses so that the response can be
sent to the new place. This implies that the retransmitted
request from the other end cannot have any changes in the payload
(except the IP header). If any other change is in the payload, 
then the stored response won't work.  This might be a bit
restrictive depending on how the protocol evolves. So, the main
advantage and difference of moving the PATH_TEST message
outside the normal window processing is that it can be a totally
new message. Hence NAT-D need not be included in every
message i guess. Perhaps, there might be something else in the
future. Even if we move the PATH_TEST message outside
the normal window, we might still have to potentially retransmit
the pending message with new address (as described here)
and hence the new processing from the receiver is still required.


> <- (B1, A3, 57R) DPD reply
> Now host A gets the packet, and he notices that the previously working
> path (A1, B2) does not work anymore, but path (A3, B1) works, so he
> updates the SAs to that new address pair
> (A3, B1, 58) N(UPDATE ADDRESSES) ->
> Host B process this new notify, and replies
> <- (B1, A3, 58R) N(UPDATE ADDRESSES reply)
> Host A and Host B again has working SAs.
> So any packets between A and B needs to be processed identically, i.e.
> all of them are finding the working address pair. After we have found
> out the working address pair, we start the actual movement request
> with the specific exchange N(UPDATE ADDRESS). Of course also the
> N(UPDATE ADDRESS) packets gets the same processing, i.e. if the
> packets do not get through we start searching for the working address
> pair.
> Depending on the protocol and contents of N(UPDATE ADDRESS) we need to
> decide what we do if the address pair changes during the N(UPDATE
> ADDRESS) exchange. I.e. if the addresses are also stored inside the
> N(UPDATE ADDRESSES) then we can see that the addresses of outer header
> and inside notify does not match, so either there is NAT or the
> initiator needed to start address pair search after construction the
> packet. In that case B can either reject the update (NAT prevention)
> or simply accept it.
> If host A needed to start address pair search, and he didn't like the
> result he can start searching new address pair and when he has found
> the one he likes, he can redo the N(UPDATE ADDRESS). 
> -- 
> kivinen <at>
> _______________________________________________
> Mobike mailing list
> Mobike <at>