Re: 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]