Subject: [Mobike] Issue 29: Editorial comments from Tero

From: <[email-masked]>
Date: Thu, 14 Jul 2005 10:26:24 +0300

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
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Jul 2005 10:47:15 +0300

>definition for "primary path").

My feeling is that, for practical reasons, we should try to
get rid of the term path, unless we use it in the route-included
sense. There are too many people that will complain when
they will see their favorite term misused :-)

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Jul 2005 12:00:50 +0300

> definition for "primary path").

Actually the "primary path" does not say weather the route of the
packet is included or not. The definition of "Path" do say that route
is included. 

> for issue 20, instead of the "initiator decides" we chose.

Better send updates then and say where it mentiones that we selected
option 1 so we can fix it. Note, that in multiple places it tries not
to say which option we have selected when describing the problem, and
only in the end of section mentions which of those options were
selected. Also decribing the other problems can still use more generic
text, even when we could use less generic one because of the some
options we selected in some other places.

This way if we decide to select some option, we do not need to modify
other parts of the document, as the generic text is still valid there.

> NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.)

True, I didn't remember it was explicitly mentioned in the text. Some
of the other optional ones are not mentioned.

> RR. I'll rephrase that paragraph to make it clearer...

Try to include also description of the attack, not only the solution,
as it do make the text more understandable to know why it is done that
way. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike