RE: intermediate mobike design draft update

[email protected] writes:
> 
> hi pasi, 
> 
> thanks for your feedback. let me give you some comments below: 
> 
>> 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 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".

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>

>> 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 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>

> > 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?)
> 
> 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