Issue 29: Editorial comments from Tero

Tero Kivinen wrote:
> > 1.3  Terminology
> > 
> >    Path
> > 
> >       A particular combination of source IP address and 
> >       destination IPaddress (note: this definition does not 
> >       consider the route taken by the packets in the network).
> 
> Any reason why the draft-ietf-mobike-design-02.txt and this
> document defined Path differently? The Path from the design
> draft do include the route, the Path here matches the more or
> less the (operantional) address pair in the design draft.
> 
> I think we should try to keep them in sync.

The design document also uses the word "path" in senses that
don't include the route taken by the packets (see e.g. the
definition for "primary path").

Also, some of the terminology in the design document needs a bit
revision, since it implicitly assumes the SCTP-like "option 1"
for issue 20, instead of the "initiator decides" we chose.

<snip>
> As we are probably going to follow the IKEv2 document style,
> which says that payload MUST come in the order they appear in
> pictures, I think we might want to keep this and IKEv2
> documents consistent. The CERTREQ is mentioned in the IKEv2
> document, so it's order is fixed, so I would move
> NAT_DETECTION_*_IP from the reply to the end, i.e:

I've actually considered this, and checked that the ordering 
is consistent with IKEv2 :-)  (According to IKEv2 Section 2.23, 
NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.)

<snip>
> >    There is one additional issue that must be taken into
> >    account.  If the destination address in the IKE_SA has
> >    been updated after the INFORMATIONAL request was sent,
> >    then it is possible that the request has been sent to
> >    several different addresses.  In this case, receiving the
> >    INFORMATIONAL response does not tell which address is the
> >    working one; thus, a new INFORMATIONAL request needs to
> >    be sent.
> 
> This should probably be clarified better, i.e. if we fall back
> to the other addresses, then the malicious peer can take those
> later messages that did reach him and send them back using
> different address pair, i.e. faking the reply of return
> routability check.

Yes, this was the idea: if we have sent the request to more than one
address (==updated the destination address in the IKE_SA, at least
currently), we need to send a new INFORMATIONAL request to check
RR. I'll rephrase that paragraph to make it clearer...
 
> There is no description here what should be done in that
> case. We need to send ACK to the N(CHANGE_PATH) quite soon, we
> cannot wait for the return routability check to finish, as it
> might be so that the initiator sends N(CHANGE_PATH) and then
> address pair stops working, thus we cannot do return
> routability check, but on the other hand initiator cannot do
> anything to fix the situation as he might have window size of
> 1, and cannot send another N(CHANGE_PATH) before the one that
> is being processed is ACK'ed.
>
> So we probably want to return ACK to N(CHANGE_PATH)
> immediately, but update the actual IP-addresses only after the
> return routability checks finish, and if during that time we
> get new N(CHANGE_PATH) we simply change the base address where
> to do return routability checks.

Yes, this was what I had in mind, too (reply to CHANGE_PATH
immediately, but update IPsec SAs only after RR check finishes).
I'll attempt to clarify this in -01.

Cheers,
Pasi