Re: Issue 59: Editorial comments from Tero (was: Comments of draft-ietf-mobike-protocol-04.txt)

Jari Arkko wrote:

> It was indeed intention that the return packet in step 3
> would be lost. We forgot to draw this in the flow, however.
> I have used something like
> 
>                                             REQ
>                   ------------------------------------------------>
>                                             RESP
>                                  /----------------------------------
> 
> elsewhere. But the real question is I guess step 4
> correctness. Yes, I actually thought that we could
> switch to another request, but as you point out,
> this is incorrect. Hmm... this means that we can't
> piggyback the RR test/cookie2 all of a sudden. Oh
> well, that means another roundtrip in this case.
> Retransmit the step 3 packet to a different address,
> then do an RR test separately.

I edited it like this:

   (The initiator suspects a problem in the currently used address pair,
   and probes its liveness.)

   3) (IP_I1:500 -> IP_R1:500)
      HDR, SK { N(NAT_DETECTION_*_IP) }  -->

      (IP_I1:500 -> IP_R1:500)
      HDR, SK { N(NAT_DETECTION_*_IP) }  -->

      ...

   (Eventually, the initiator gives up on the current address pair, and
   tests the other available address pair.)

   4) (IP_I1:500 -> IP_R2:500)
      HDR, SK { N(NAT_DETECTION_*_IP) }

                            <--  (IP_R2:500 -> IP_I1:500)
                                 HDR, SK { N(NAT_DETECTION_*_IP) }

   (This worked, and the initiator requests the peer to switch to new
   addresses.)

   5) (IP_I1:500 -> IP_R2:500)
      HDR, SK { N(UPDATE_SA_ADDRESSES),
                N(NAT_DETECTION_*_IP),
                N(COOKIE2) }  -->

                            <--  (IP_R2:500 -> IP_I1:500)
                                 HDR, SK { N(NAT_DETECTION_*_IP),
                                           N(COOKIE2) }

Does this look right?

Best regards,
Pasi