Subject: [Mobike] intermediate mobike design draft update

From: Tschofenig Hannes <[email-masked]>
Date: Sat, 22 Jan 2005 16:27:23 +0100

hi all, 

based on the review comments i have compiled an intermediate draft version.
you can find the draft at:

http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_22Jan2005.tx
t
http://www.tschofenig.com/TEMP/TEMP-draft-ietf-mobike-design-02_22Jan2005.ht
ml

ciao
hannes
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: <[email-masked]>
Date: Wed, 26 Jan 2005 19:02:40 +0200

Hi,

I have some comments and suggestions about the terminology about
addresses/pairs/paths in mobike-design-02.

1)

Currently the definition of "preferred address pair" is quite
imprecise, since it unnecessarily mixes what is preferred with
what is actually happening. Also, it's not quite clear what's
the difference between "preferred address pair" and "primary
path".

I'd suggest we replace both of them with a new term, say
"current path" (or "current address pair"), that means the
addresses that are currently used by the peer as the tunnel
header addresses of IPsec packets (of IPsec SAs associated
with this IKE SA).

I think we had rough consensus on issue 8 (scope of SA changes);
thus, each peer has only a single "current path", and in stable
situations (when nothing MOBIKE-related has been happening
recently), the "current path" is equal to the path used for
sending IKEv2 requests (for e.g. rekeying).

Both peers A and B have their own current path, and they're not
always equal (they are never equal if NATs are involved, and
even if no NATs are involved, they are different for at least
short periods of time when something MOBIKE-related is
happening).

It's a separate question whether the current paths should be
equal in stable situations (where NATs are not present). In
MOPO-IKE, they are (the responder uses the path selected by the
initiator).  In SCTP, they're not (each peer makes its selection
independently).  I'm not sure which is the case for
draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?)

2)

Most of the time, RFC2960 uses the word "path" to mean a 
combination of source and destination address (and mostly
avoids the term "address pair"). I much prefer the word "path",
and I'd suggest we use that one (but whichever we use, it
should be consistent throughout the whole document).

3) 

The definition of "Available address" says that "Where IPv4 is
considered, it is not an RFC 1918 [RFC1918] address." Why? For
instance, if the peers are connected to some private network
that happens to use RFC 1918 addresses, and there are no NATs
involved, why they're not allowed to use MOBIKE?  (I'd suggest
removing this bullet.)

Best regards,
Pasi

---

From: Tschofenig Hannes <[email-masked]>
Date: Sat, 29 Jan 2005 14:43:31 +0100

hi pasi, 

> header addresses of IPsec packets (of IPsec SAs associated

i tried to prevent reinventing new terms here and used the term 'preferred
address' from 
<draft-ietf-hip-mm-00.txt>

it is true that the definition of preferred address pair and primary path
point to the same concept. 

i have replaced the term "preferred address pair" with "primary path". 

> sending IKEv2 requests (for e.g. rekeying).

true. 

> short periods of time when something MOBIKE-related is

it is true that each peer has it's own view of the world and there might be
an inconsistency of the established state information. ideally, the state of
the two peers should be synchronized. 

based on <draft-arkko-multi6dt-failure-detection-00.txt> i would, however,
argue that we both peers try to have the same 
primary path. this means, for example, if peer 1 has a preferred address
ip_a and peer 2 has a preferred address ip_b then the path is between ip_a
<-> ip_b for both peers. 

we could also utilize something like an undirectionally operational address
pair (definition from <draft-arkko-multi6dt-failure-detection-00.txt>). this
would mean (with the above example) that peer 1 would send messages to ip_b
at peer 2 and peer 2 would return messages to an address ip_a2 (although the
source address of the mesgs hitting peer 2 use ip_a1). 

this approach would, however, cause problems with nat handling. 

> draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?)
regarding sctp there is very little text on how addresses are selected (at
least i haven't found the text paragraphs). 
it is just a policy issue. since we are concerned about nat handling we
should talk about bidirectionally operational address pairs. 

> should be consistent throughout the whole document).

i agree with you. 

> involved, why they're not allowed to use MOBIKE?  (I'd suggest

i fully agree with you. i asked myself the same question when i read 
but then i forgot it again when i copied the text from jari's draft to this
draft. 

thanks for your feedback. 

ciao
hannes

---

From: <[email-masked]>
Date: Mon, 31 Jan 2005 18:08:54 +0200

[email-masked] writes:
> i tried to prevent reinventing new terms here and used the
> term 'preferred address' from <draft-ietf-hip-mm-00.txt>
> 
> it is true that the definition of preferred address pair and
> primary path point to the same concept.
> 

Hmm... I think they _don't_ actually point to the same concept...

"Preferred address" is about preferences, and "preferred address
pair" is just the combination of A's and B's preferred address.
But this is not necessarily always the src/dst address that is 
actually put to outbound packets.

To give a concrete example, suppose that A and B have addresses
A1,A2,B1,B2; A prefers A1 and B prefers B1, and both parties
have "current path" A1,B1.

Now, suppose that A does dead peer detection and does not get
a response (even after retransmissions). But if A notices that
A2,B2 works, it sounds very reasonable to change the current
path to that (and then do whatever MOBIKE signaling is necessary).

So, if the "preferred address pair" and "current path" are the
same concept, that seems to imply that one party can change the
other one's preferred address? (But this is not in line with the
current definition of "preferred address"... so I think we have
two different concepts here)

<snip>

> it is true that each peer has it's own view of the world and
> there might be an inconsistency of the established state
> information.  ideally, the state of the two peers should be
> synchronized.

I'm not so sure... This is not really a synchronization problem,
but a preference combination problem. Both A and B have their
own preferences, and some information about the other's
preferences.  But this does not guarantee that they end up 
with the same "current path".

For instance, if A prefers A1 to A2, and B prefers B1 to B2;
A1,B1 doesn't work, but both A1,B2 and A2,B1 do, which one
should be the single synchronized "current path"?

It seems that if we want both parties to have the same "current
path" (in stable situations), either one party has to make the
decision (like in MOPO-IKE), or the we have to severely restrict
the kinds of preferences that can be used, and give the decision
algorithm in the spec (so that both parties always end up with
the same path).

(It's of course a good question whether having the same "current
path" in stable situations is necessary or not.  I think it
simplifies things, and that's why in MOPO-IKE the initiator's
choice is used in stable situations.)

<snip>

> regarding sctp there is very little text on how addresses are
> selected (at least i haven't found the text paragraphs).  it
> is just a policy issue. since we are concerned about nat
> handling we should talk about bidirectionally operational
> address pairs.

Yes, I think SCTP leaves address selection as a policy
issue. And since both ends have their own policy, they can end
up using different addresses (even if all address pairs work in
both directions).

Best regards,
Pasi