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

Hi Hannes,

Comments inline.

Atul

> -----Original Message-----
> From: ext Tschofenig Hannes [mailto:[email protected]]
> Sent: Thursday, February 10, 2005 4:17 PM
> To: Sharma Atul (Nokia-ES/Boston); Eronen Pasi (Nokia-NRC/Helsinki);
> [email protected]
> Subject: AW: [Mobike] New issue 19: Same addresses for both 
> directions?
> 
> 
> # hi atul, 
> 
> 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
> 
> # i think we clarified this issue. we came to the conclusion that
> - if both peers only have one address (or only one address 
> communicated to
> the other end) then you cannot support a simultaneous address change
> (without a third party). 
> - in the case where they each peer has more addresses and 
> communicates them
> to the other peer then a simultaneous address change (without 
> involvement of
> a third party).   
> 
> # this issue is independent from the issue discussed below. 

The issues are independent. But the scenario Pasi was talking about
involved interaction of two issues: (1) Simultaneous change in addresses
 and (2) ASYMMETRICALLY doing (1)

This is all I was refering to.

> 	* 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.
> 
> # yes but independent from the aspect of 'bidirectionally operational
> address pair' and 
> 'undirectionally operational address pair'. 
> 
> 	* 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)?
> 
> # ike responds to the address where the request came from. 
> additionally only
> a single address is supported. hence, there this issue does 
> not appear. 
>  
> 
> 	  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.
> # i would say 'no'. we cannot make a bof on every issue. 

The issue is a major one, namely that of "Asymmetric Security". Asymmetry
could be in tunnel endpoint addresses (like discussed here); or asymmetry
could be in the tunnels (not discussed here); or asymmetry in the gateways
participating in secure transmission (not discussed here).

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