RE: issue 11 -- window size

The only hang-up I have is Jari's question below; namely, what exactly
constitutes "information needed to do mobility 
and path testing"?  It has to be fairly lightweight since the expectation is
that this information would be included in each packet.

-g

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Stephane Beaulieu
> Sent: Wednesday, April 06, 2005 7:31 AM
> To: 'Tero Kivinen'; 'Jari Arkko'
> Cc: [email protected]
> Subject: RE: [Mobike] 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
> > 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>