-------------------- IETF59 MOBIKE WG minutes: James Kempf: If Mobile IP is being used simultaneously, return routability checks would redundant. Could we pass information from there? Paul Hoffman: Would that be a layering violation? James: Signalling efficiency is important. But it's worthwhile at looking at this, otherwise people might not take it seriously from deployment viewpoint. Pekka Nikander: At multi6 there was idea called SLAP, now draft called CLP which discusses how to share RR tasks between protocols and more. Charlie Perkins: Is it already layering violation to do RR checks at all? And 2nd question, do you have any performance requirements? James: Since RR is useful in many contexts, maybe separate RR to another protocol. Tero Kivinen: I don't know if we have any performance requirements. And we try to stay away from routers, but e.g. SGW is kind of router. Paul: Not in charter (performance reqs). Tero: Scenario laptop to corporate VPN, user doesn't notice when something happens, order of tens of seconds, but not two minutes. This is not about <1s recovery time. Lauri Tarkkala: RR, we are doing more than RR, also checking that valid IKE SA exists at the other address (also SPIs etc) Tero: DPD and RR are different things, but we can use same messages in IKE ... Lauri: DPD again, we need special MOBIKE handling for all IKEv2 exchanges, not just DPD exchanges, because any exchange in IKEv2 can be DPD exchange Stephen Kent: agree with Lauri and disagree with Charlie: We are doing RR in secure fashion, not vulnerable to MITM attacks, so a separate "RR protocol" is probably not a good idea. Paul: We need to capture these kinds of discussions in the design document, so we can find out why we did things. Please send to mailing list. Charlie Perkins: I would correct something that was said about MIP return routability. A home agent discovery is authenticated Stephen: I did not say anything about Mobile IP return routability, just generic return routability. Jari Arkko: I do not think we can have a generic return routability module. There are different RR mechanisms in different protocols, because we need them to do different things. -------------------- Jari Arkko (2004-10-31): Background: a number of protocols employ return routability tests. In the mobility space we have this at least in MOBIKE, Mobile IPv6, MULTI6, and HIP. Tero's design document discusses some differences these tests have in different contexts; not all do exactly the same thing even if all at least verify there's someone willing to respond on the path towards the tested address. I would like to suggest that we do our own specific type of test, but allow same tests to be "reused" across protocols where this makes sense. That is, in MOBIKE we do our own test that verifies liveness of the address and that the peer is indeed still the same IKEv2 node and has knowledge of some secret keying material. In addition, we add a note saying that the use of the results of this test may be possible in other protocol layers*. Ok for everyone? --Jari *) The example that comes to my mind is that since the mobile node - home agent interface in mobile IPv6 runs with IPsec, then the use of MOBIKE in that context would provide an RR test to home registrations. That does not exist in Mobile IPv6 at the moment, but if it were included then Mobile IPv6 home agent service could easier be offered to "unknown" peers. Currently "unknown" peers are only support as correspondent nodes. -------------------- James Kempf (2004-11-01): IMHO, the lack of HA RR test in RFC 3775 is a residual vulnerability. RFC 3775 says that network operators should monitor their clients traffic and cut them off if they try bombing. But how is an operator supposed to know that? In the absence of any RR test, there's no way for the HA to know whether the MN is at the care of address to which it is directing a video stream, or whether its a bombing attack. This kind of insider attack is still possible. So I think this is an excellent idea. In fact, I think it should be used not just with "unknown" peers but also with known clients of the HA. -------------------- Atul Sharma (2004-11-01): I think RR should only be attempted after MOBIKE/IKE informational exchange has been validated. It should not be attempted for every possible address updates. RR is useful for an authenticated attacker only. For an unauthenticated attacker (psuedo-NAT attack) it is wasteful. I did not understand the comment on "...but if it were included then Mobile IPv6 home agent service could easier be offered to unknown peers." Given that such a RR test done by MOBIKE can be used elsewhere and similarly connectivity information elsewhere could be used in MOBIKE, MOBIKE should work on defining such cross-layer/cross-protocol APIs. -------------------- Jari Arkko (2004-11-08): We have gotten less input on this issue than on others, but the way that I read this is the following: (1) We have a basic agreement that we define what MOBIKE RR provides, and if other protocols are happy with that then they can use it without doing their own. (2) THere was a discussion if this works the other way around, i.e., from another protocol to MOBIKE. Tero argued for this and Pasi presented a counter argument. I think the counter argument made sense, and since Tero was silent I'm going to assume you were OK with it too. (3) Atul suggested that APIs be worked on. We at the IETF are typically not chartered to work on APIs; I'm sure you see obvious ways of doing this in your implementation, however. But in MOBIKE, we are chartered to actually work on one API, the PFKEY API. It may be that this would be a part of the that work, or maybe not -- time will tell. But its clear that it is not a requirement for the protocol work to proceed. So we'll remember this when and if we get to the PFKEY part. (Folks: we need to produce are base spec before we get any further!) In conclusion I think we can close this one too. -------------------- Jari Arkko (2004-11-29): We had a proposal where the results of MOBIKE RR test could be used by other protocols, if deemed useful by the designers of these other protocols. There seems to be general support for this proposal. We also had a discussion about whether this would make sense in the Mobile IPv6 space; different opinions and technical alternatives were offered. That's OK, however, because we don't get to decide this part of the problem in WG. But we can now move forward with the original issue. Here's my proposalon what the design draft should say about the matter: Replace the current text MOBIKE might also want to export the information it has done the return routability checks to the other modules, like Mobile IP, so Mobile IP does not need to do return routability checks again, if it is satisfied with the level of checks done by the MOBIKE. with this new Section: X. Employing MOBIKE results in other protocols If MOBIKE has learned about new locations or verified the validity of an address through a return routability test, can this information be useful for other protocols? When considering the basic MOBIKE VPN scenario, the answer is no. Transport and application layer protocols running inside the VPN tunnel have no consideration about the outer addresses or their status. Similarly, IP layer tunnel termination at a gateway rather than a host endpoint limits the "other protocols" that could be informed -- all application protocols at the other side are running in a node that is unaware of IPsec, IKE, or MOBIKE. However, it is conceivable that future uses or extensions of MOBIKE make such information distribution useful. For instance, if transport mode MOBIKE and SCTP were made to work together, it would likely be useful for SCTP to learn about the new addresses at the same time as MOBIKE learns them. Similarly, various IP layer mechanisms might make use of the fact that a return routability test of a specific type has already been performed. However, in all of these cases careful consideration should be applied. This consideration should answer to questions such as whether other alternative sources exist for the information, whether dependencies are created between parts that prior to this had no depedencies, and what the impacts in terms of number of messages or latency are. Reference [draft-crocker-celp-00.txt] discussed the use of common locator information pools in IPv6 multihoming context; it assumed that both transport and IP layer solutions would be used for providing multihoming, and that it would be beneficial for different protocols to coordinate their results in some manner, for instance by sharing experienced throughput information for address pairs. This may apply to MOBIKE as well, assuming it co-exists with non-IPsec protocols that are faced with the same multiaddressing choices. Nevertheless, all of this is outside the scope of current MOBIKE -------------------- Closed issue on 2004-12-13 with text "Possible to do in the future, but beyond the current scope of MOBIKE WG". --------------------