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.
> 
There is nothing wrong with Tero's proposal. I like it. But we should at least
look at other options. They are :

1) Define a separate window for PATH_TEST messages
2) Do the PATH_TEST message outside the protection IKE SA [MOPO protocol]

This gives the flexibility in what PATH_TEST messages contain. Otherwise, you have
to include all possible options with all the packets if you ever do MOBIKE for that
IKE SA. Once we know the new PATH,  rest of it follows as per Tero's mail.
Another advantage of keeping PATH_TEST message separate (like in (1) and (2)
above), is that we can look for a new PATH even when there is no failure. This
might be a useful feature. I don't know whether it is possible with Tero's proposal.

-mohan

> 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