RE: issue 11 -- window size

Given the limitation of window sizes, I think this proposal is the best
we've discussed so far.

Unless someone can find something technically wrong with Tero's proposal, I
vote that we proceed with this approach.

Stephane. 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Tero Kivinen
> Sent: Tuesday, April 05, 2005 3:58 AM
> To: Jari Arkko
> Cc: [email protected]
> Subject: Re: [Mobike] issue 11 -- window size
> 
> Jari Arkko writes:
> > (So what exactly would "information needed to do mobility and path 
> > testing" constitute?
> 
> Depends about the answers to issue 3...
> 
> > Presumably, one of the things that we would probably need 
> is a NAT-D 
> > payload.
> 
> Not necessarely, in the simplies form it would be simply 
> outer IP addresses and ports.
> 
> > Would this mean that if we have send request X and later 
> realize that 
> > we don't get a response and have to retransmit on another, new 
> > interface, we resubmit X exactly as-is?
> 
> Yes. The packet must be resubmitted as-is, only IP-addresses 
> and ports can change. There responder might be taking HASH of 
> the packet when processing it and store the reply packet, and 
> when he sees the retransmission he must be able to match the 
> hash of the previous retransmission to this new one. 
> 
> > Or can we add "mobility data", such as NAT-D payload?
> 
> No, we cannot add those. 
> 
> > Or perhaps "mobility data" is simply the source address and NAT-D 
> > payloads are always included...?)
> 
> That would be one option.
> 
> I.e. in the simpliest way to get the protocol working would 
> be something like this:
> 
> Host A has 3 IP-addresses A1, A2, A3
> Host B has 2 IP-addresses B1, B2
> 
> IKE SA is currently using (A1, B1)
> 
> Host A starts CREATE_CHILD_SA (message ID 55), and sends packet to B.
> 
> (A1, B1, 55) CREATE_CHILD_SA -> (dropped)
> 
> 		There is something wrong with the path A1,B1 and
> 		packet is dropped (B1 does not work...)
> 
> Host A retransmits few times:
> 
> (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) 
> CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped)
> 
> Host A notices he is not getting packets back, he starts 
> searching for the working address pair:
> 
> (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) 
> CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> 
> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, 
> 55) CREATE_CHILD_SA -> Host B gets the packet..
> 
> 		Host B will immediately notice that there is something
> 		wrong with the path as the Host A is using different
> 		ports, but he simply continues processing the packet
> 		normally, and replies (with message id 55R) to the
> 		reversed addresses
> 
> 		<- (B2, A1, 55R) CREATE_CHILD_SA reply
> 
> Host A gets the packet and notices that he has found a working path.
> He decides that the he should move the traffic to that new 
> address pair too, so he sends address update packet to host B:
> 
> (A1, B2, 56) N(UPDATE ADDRESSES) ->
> 
> 		Host B updates his SAs to new address pair, and
> 		replies.
> 
> 		<- (B2, A1, 56R) N(UPDATE ADDRESS reply)
> 
> 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
> 		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.
> 
> 		<- (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). 
> --
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>