Subject: [Mobike] New issue 19: Same addresses for both directions?

From: <[email-masked]>
Date: Thu, 3 Feb 2005 11:16:35 +0200

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-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: <[email-masked]>
Date: Thu, 3 Feb 2005 10:08:37 -0500

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-masked] 
> [mailto:[email-masked]]On
> Behalf Of ext 
> Sent: Thursday, February 03, 2005 4:17 AM
> To: [email-masked]
> Subject: [Mobike] New issue 19: Same addresses for both directions?
> 
> 
> Hi,
>

---

From: <[email-masked]>
Date: Thu, 3 Feb 2005 17:44:05 +0200

>   some kind of simultaneous change of addresses can be 

It was already decided a while ago that simultaneous change
of addresses will be supported (see issues #13 and #17).

>   such an asymmetry may not be allowed)?

Hmm... issue 19 is about asymmetry for IPsec traffic (ESP/AH),
not IKEv2/MOBIKE messages (I don't think anyone is proposing 
breaking the rule that IKE responses are sent to the same 
address the request came from).

If the MOBIKE protocol ends up sending all addresses of both
parties in the initial IKE negotiations (IKE_SA_INIT/IKE_AUTH),
and each peer selects the addresses for outbound IPsec SAs
independently, then conceivably asymmetry could happen 
even at that point.

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

The BoF procedure is explained in RFC 2418. But I don't 
quite see why a BoF would be better place than MOBIKE WG
to discuss this?

Best regards,
Pasi

---

From: <[email-masked]>
Date: Thu, 3 Feb 2005 11:15:07 -0500

Hi Pasi,

Response inline.

Best,
Atul

> From: Eronen Pasi (Nokia-NRC/Helsinki) 
> Sent: Thursday, February 03, 2005 10:44 AM
> To: Sharma Atul (Nokia-ES/Boston); [email-masked]
> Subject: RE: [Mobike] New issue 19: Same addresses for both 
> directions?
> 
> 
> Atul Sharma writes:
> > 

I agree. I was referring that this scenario is result of two issues.
Not that issue of simultaneous address change has not been agreed upon.

> independently, then conceivably asymmetry could happen 

That would mean in SAD the incoming and outgoing SAs of the same
SA pair can have different tunnel endpoints. Now that in the 
incoming direction a variation of src,dst addresses can be used
for searching an SA, we may have to match the src,dst of the
IPsec traffic in both direction. I do not know if such an asymmetry
is allowed on IPsec traffic (we agree it is not allowed on IKE/MOBIKE
traffic).

> quite see why a BoF would be better place than MOBIKE WG

Because it has implications for other scenarios as well, for example
a Mobile IP End-to-End Asymmetric Security.

---

From: <[email-masked]>
Date: Fri, 4 Feb 2005 11:00:44 +0200

Atul Sharma wrote:
> That would mean in SAD the incoming and outgoing SAs of the
> same SA pair can have different tunnel endpoints. Now that in
> the incoming direction a variation of src,dst addresses can be
> used for searching an SA, we may have to match the src,dst of
> the IPsec traffic in both direction. I do not know if such an
> asymmetry is allowed on IPsec traffic (we agree it is not
> allowed on IKE/MOBIKE traffic).

Hmm... when searching the right SA for inbound (encrypted)
packets, the (outer) src/dst addresses are normally not used 
in rfc2401bis (unless we have SAs where they're multicast
addresses, but that's not possible with IKEv2).

So I don't think there's any fundamental problem in the
asymmetry (but IMHO trying to keep it symmetric probably
will be simpler).

Best regards,
Pasi

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 10 Feb 2005 22:15:46 +0100

# hi pasi 

# thanks for raising this issue. please find my comments inline:

Hi,

# this is related to the terms 'Bidirectionally operational address pair'
and 
'Undirectionally operational address pair' introduced in 
<draft-ietf-multi6-failure-detection-00.txt> 

# this means that we assumed so far that we will mainly focus on
bidirectionally operational address pairs since
we assumed the possible placement of nats and firewalls along the path. this
means two nodes, a and b, communicating with each other communicate in the
following fashion:

node a                           node b

 source ip=a1, 
 destination ip=b1
     ------------------------------> 
                                 
                           source ip=b1
                           destination ip=a1
     <------------------------------

the alternative would be to allow the following communication:

node a                           node b

 source ip=a1, 
 destination ip=b1
     ------------------------------> 
                                 
                           source ip=b2
                           destination ip=a3
     <------------------------------

# there might not only be an impact with regard to nats and firewalls but
also with regard to congestion and path characteristics since routing
asymmetry will be quite high if you use different ip addresses (which might
belong to different interfaces). 

# and each peer will have a preference on the address used for outgoing
traffic (because of costs). 

# yes. 

# yes. 

- It seems that this does not yet uniquely determine the pair of
  addresses that gets used.

# yes. this was also one of the conclusions of jari's presentation at the
last ietf with regard to 
<draft-ietf-multi6-failure-detection-00.txt> 

 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.

# certainly. 

# i think it is not uncommon to return an ip packet to the place where it
came from. 
# do you really need to force something? i think it is more likely that you
will be 
able to return a packet when you just send it back to the address where it
came from 
rather than sending it to another address. 

# i think that this is not necessary. 

# that's certainly true. sctp does not care about nats and firewalls. 
i am not so sure about their security as well.

# certainly. if we think of a regular scenario then we have the mobile node
starting with the communication. 
the mn will contact the security gateway using the basic ikev2/mobike
exchange. as a result the the address 
pair used by them is already chosen. 

# now, if the mobile node changes its address then some protocol
interactions are necessary. 

#if the mn has only one interface then the protocol interactions are roughly
clear. we can only hope that the security gateway does not remove its state
too quickly (e.g, because of the dead peer detection mechanism) to give the
mn some chance to complete the network attachment procedures. 

Comments are welcome!

# i think we should!
thanks for the issue. 

# ciao
# hannes

Best regards,
Pasi

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 10 Feb 2005 22:17:12 +0100

# hi atul, 

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

# yes but independent from the aspect of 'bidirectionally operational
address pair' and 
'undirectionally operational address pair'. 

# ike responds to the address where the request came from. additionally only
a single address is supported. hence, there this issue does not appear. 

	  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. 

# ciao
# hannes

Atul

---

From: <[email-masked]>
Date: Fri, 11 Feb 2005 09:47:35 -0500

Hi Hannes,

Comments inline.

Atul

> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: Thursday, February 10, 2005 4:17 PM
> To: Sharma Atul (Nokia-ES/Boston); Eronen Pasi (Nokia-NRC/Helsinki);
> [email-masked]
> Subject: AW: [Mobike] New issue 19: Same addresses for both 
> directions?
> 
> 
> # hi atul, 
> 

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.

> requested 

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