-------------------- Pasi Eronen (2005-02-03): 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. -------------------- Atul Sharma (2005-02-03): 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. -------------------- (issue list editor note: see mailing list archive for more messages in February-March 2005.) -------------------- Jari Arkko (2005-05-13): It looks to me that the decision on issue 20 (who decides) is the main determining factor issue 19 as well. If issue 20 resolution is that the initiator decides, then it more or less follows that we have same addresses in both directions. We can imagine different addresses even in this case, but it does not appear to be very useful or necessary. On the other hand, if we decide in 20 that the decisions are independent, then it may in fact be very hard to ensure that the two directions use the same addresses. As a result, allowing different addresses would make more sense in this scenario. My conclusion is that we should focus on trying to solve issue 20 first. -------------------- Jari Arkko (2005-05-29): I wrote earlier tha the decision on issue 20 (who decides) also has a big impact on issue 19. If we had decided in 20 that the decisions are independent, then it might in fact have been very hard to ensure that the two directions use the same addresses. As a result, allowing different addresses would make more sense in this scenario. But we ended up with "initiator decides". Therefore the deciding entity knows enough about the situation to be able to use the same address pairs in both directions. Of course, this does not necessarily have to be done. We could develop a protocol that provides independent addresses, yet would be controlled by the initiator. (Probably with some cost in terms of complexity. And I'm not quite sure how to deal with NATs and keepalives in that kind of a scenario.) How do you folks feel about this? Please post your comments by Friday, June 3rd. -------------------- Geoffrey Huang (2005-05-30): > But we ended up with "initiator decides". Therefore the > deciding entity knows enough about the situation to be > able to use the same address pairs in both directions. This makes sense to me - it's the logical progression from what was decided for Issue 20. > Of course, this does not necessarily have to be done. > We could develop a protocol that provides independent > addresses, yet would be controlled by the initiator. > (Probably with some cost in terms of complexity. > And I'm not quite sure how to deal with NATs and > keepalives in that kind of a scenario.) I can't imagine why this would be useful. In which scenarios wouldn't we want the initiator to decide which address pairs to use in both directions? -------------------- Mohan Parthasarathy (2005-06-01) Hmm.. we chose the "initiator decides" option because it works well with NAT. So, i am not sure i understand the issue here. Here, the initiator finds two sets of addresses (one for upstream and one for downstream traffic) and updates the peer providing information about which address pair to be used for downlink and which address to be used for up link. I would assume that it is the initiator's responsibility for sending keep alives. So, what is the issue here with NATs ? If the initiator is multi-homed and connected simultaneously to more than one access (e.g. UMTS and WLAN) at the same time, there might be some usefulness in having different paths for upstream and downstream traffic though i don't know really what it is :-) -------------------- Pasi Eronen (2005-06-02): I sort of agree with this: there might be some usefulness in this, but I can't really give any good examples. Thus, I think we should follow the KISS principle and assume both directions use the same address pair. (If it turns out later that there is some real important use for this, it can be added then.) -------------------- Jari Arkko (2005-06-02): >(If it turns out later that >there is some real important use for this, it can be added then.) > > This is a good observation. In some cases we make decisions that cannot be easily reversed; in this case we are making a limitation that could (or so it appears) be easily lifted when in year N we want to use MOBIKE for something that requires it. But I would personnally really like to do only the absolutely necessary things right now, if not for other reason than the ability to complete the RFC as soon as possible. -------------------- Mohan Parthasarathy (2005-06-02) Agreed. -------------------- Jari Arkko (2005-06-02): Perhaps I didn't think of it through well enough. Lets see... if we pick different address pairs for the incoming and outgoing traffic from the client, how would the incoming traffic be able to enter through the port 500 pinhole that the client has opened for the outgoing direction by the initiation of the IKEv2 exchange? -------------------- Hannes Tschofenig (2005-06-03): we should use the same addresses in both directions. this seems to be much easier (from a protocol point of view and regarding the traversal of nats/stateful packet filtering firewalls). -------------------- Bill Sommerfeld (2005-06-03): I haven't seen a compelling scenario which requires a different address-pair in each direction. That said, "initiator decides" effectively means "initiator tells responder which addresses the responder should use when sending" and may be silent about what the initiator does when sending -- unless we require the reciever to reject traffic to/from the wrong address pair. So I think, given our resolution to #20, #19 becomes almost a local matter on the initiator. -------------------- Francis Dupont (2005-06-03): It seems we lost the basic idea: the only critical thing is the destination address the peer uses to send packets to us, and we really need to control it, this is why the option 3 for issue 20 is *not* the right one. About issue 19, I believe: - an SA pair MUST be created with the same address pair (just to avoid to provide a way to do something else) - an SA pair SHOULD use the same address pair (this doesn't close the door and avoid a spurious requirement). --------------------