RE: New issue 19: Same addresses for both directions?

I think this is interaction of two issues here. I tried
to raise this scenario a couple of days ago to Hannes:
	* Simultaneous change of addresses
	* Different IKE address pair in the two directions (Asymmetry)

My thoughts on these are:

	* If we have prior knowledge of addresses at the other end,
	  some kind of simultaneous change of addresses can be supported.

	* For asymmetry, clearly initial IKE negotiations can not
	  support it. (Does it?) In your scenario, at some point in
	  time A1-B1 (or other symmetric pair) IKE negotiations should 
	  have succeeded. Question is once IKE has succeeded can MOBIKE,
	  allow such an asymmetry? For how long (at next renegotiations 
	  such an asymmetry may not be allowed)?

	  Also, the issue is of more general nature than just restricted
	  to MOBIKE. I have been meaning to raise this issue of asymmetry 
	  for sometime to get a new BoF. But am not familiar with the BoF 
	  procedure.

	  What do folks on this list think: a new BoF could be requested 
	  to handle IKE asymmetry? Clearly issue has more broader implications.


Atul

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On
> Behalf Of ext 
> Sent: Thursday, February 03, 2005 4:17 AM
> To: [email protected]
> Subject: [Mobike] New issue 19: Same addresses for both directions?
> 
> 
> Hi,
> 
> The discussion about terminology in the design draft brought 
> up a (somewhat) new issue about whether IPsec traffic in both
> directions should use the same pair of addresses (in stable
> situations), or whether each peer makes the selection for its
> outbound traffic independently.
> 
> By "stable situations", I mean long periods of time when 
> nothing MOBIKE-related is happening (it's clear that when 
> traffic is being moved from one pair of addresses to another, 
> the peers aren't necessarily synchronized all the time).
> 
> Some thoughts about this (more welcome, this is very
> preliminary):
> 
> - Each peer can have some preferences about, e.g., on 
>   which address it wants to receive traffic from the 
>   other peer.
> 
> - Some information about these preferences can be sent to 
>   the other peer in MOBIKE payloads. Current proposals have 
>   an ordered list of addresses.
> 
> - Each peer thus has its own preferences, and some limited
>   information about the other's preferences. But the choice
>   is also constrained by what paths happen to work currently.
> 
> - It seems that this does not yet uniquely determine the pair of
>   addresses that gets used. For instance, assume that peer A
>   prefers address A1 to A2, and peer B prefers address B1 to B2.
>   If, however, the combination A1,B1 does not work, but all
>   others do, A could choose A1,B2 and B could choose B1,A2.
> 
> - One way to force the same addresses is that one of the peers 
>   makes the decision, and tells the other (in MOPO-IKE, it's 
>   always the initiator; presumably, some more complex protocol 
>   could, e.g., try to negotiate it in the beginning, or choose 
>   randomly.)
> 
> - Another way would be to specify the decision making 
>   algorithm in the protocol specification. This would mean that 
>   the decision is always based on whatever limited preferences 
>   information can be encoded to the payloads (while if one party 
>   always makes the decision, it can utilize more information 
>   about its own preferences).
> 
> - More ways to ensure that the same address pair gets chosen 
>   might be possible...
> 
> - But a good question is whether this is necessary at all. My  
>   understanding of SCTP is that address selection is left as a 
>   policy issue, and since both ends have their own policy, they 
>   can end up using different addresses.
> 
> - In "mobile client connected to VPN gateway" situations, 
>   I think it would make sense that the client's preferences
>   (e.g. whether to use WLAN or GPRS) are followed whenever 
>   possible.
> 
> Comments are welcome!
> 
> (Hannes: perhaps something about this could be added to the
> design draft as well?)
> 
> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>