AW: intermediate mobike design draft update

hi pasi, 

thanks for your comments. please see my response below: 

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

it is true that 
a) node A cannot force node B to change its preferred address
b) we need some terminology to differentiate the different cases. 

to continue your example above it is necessary for node A to communicate to
node B that the preferred address B1 is not operational anymore (node B
might have noticed it already). node B certainly needs to switch its
preferred address as well, for example to B2. as such you might want to
interpret the message transmitted by node A towards node B as a hint to
switch its preferred address (if node B hasn't found it out already by some
other means).  

hence, i am not sure whether we should introduce separate terminology for
the case where
a) node A and node B have synchronized state
b) node A and node B do not have synchronized state

ideally, the duration of missing state synchronization should be short.  
hence, we switch from one preferred address pair to another. 

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

before the problem in your example started node A and node B knew that they
are reachable at a certain address. additionally the knew that there are
some additional addresses that they can used for communication. 

suddenly node A recognized that a certain path is non-operational anymore. 
node B might have also recognized it and executes connectivity tests on the
available address combinations. 

after some mobike messages between node A and node B they should both have
the same state information again, namely node A and node B are reachable at
a certain address pair. 

i don't know whether the term 'synchronization problem' or 'preference
combination problem' is the better term for it. 

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

if a1,b1 does not work then it certainly not be the preferred address pair. 
the step from the preferred address of each node is not just picking each
node's preferred address and to put them together. 
i think we should make this more explicit in the document. the choice of a
preferred address selected by a node might be based on the available
bandwidth of the link, cost of the link, etc., or even arbitrarily selected.


the choice of a preferred address pair is certainly impacted by the question
whether a particular path is operational. 


> 
> 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).
true. 

ciao
hannes

> 
> Best regards,
> Pasi
>