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

# hi pasi 

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


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.

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


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.

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

 
- Some information about these preferences can be sent to 
  the other peer in MOBIKE payloads. Current proposals have 
  an ordered list of addresses.


# yes. 

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

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

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

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

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

# i think that this is not necessary. 

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

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

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

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

(Hannes: perhaps something about this could be added to the
design draft as well?)

# i think we should!
thanks for the issue. 

# ciao
# hannes

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike