-------------------- TEMP-draft-kivinen-mobike-design-00.txt: 3.2 When to do Return Routability Checks One of the decisions that needs to be done, when to do return routability checks. The simple approach is to do it always. Another option is to do it every time new IP-address is taken in to use. The basic format of the return routability check could be similar than dead-peer-detection, but the problem is that if that fails then the IKEv2 specification requires the IKE SA to be deleted. Because of this we might need to do some kind of other exchange. If the other end is SGW with limited set of fixed IP-addresses, then the SGW can get certificate having all the IP-addresses in the certificate. If the certificate includes all the IP-addresses, it is no point to do weaker return routability check, the data in the certificate is already properly authenticated after the IKE SA is created, so the peer might simply use that and ignore return routability checks. Another option is to use draft-dupont-mipv6-3bombing [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send the update from some other address than indicated preferred address. Final option would simply not to do return routability checks at all. If we use indirect change notifications then we only move to the new IP address after successfull dead-peer-detection on the new address, which is already return routability check. In the direct change notifications the authenticated peer have given out authenticated IP-address, thus we could simply trust the other end. There is no way external attacker can cause any attacks, but we are not protected by the internal attacker, i.e. the authenticatede peer forwarding its traffic to the new address. On the other hand we do know the identity of the peer in that case. -------------------- IETF59 MOBIKE WG minutes: [Francis's presentation] - Policies (what kind of verification you need for addresses, i.e. RR or certificates or something else) [Tero's protocol presentation, Direct Indication of Change] - If new preferred address is unknown, move traffic immediately, and start return routability checks (some might want to delay moving). [Tero's design presentation, when to do return routability checks] Return Routability Checks: - When to do them? - Everytime we change address? - Only when we start to use new address not used before? - Never? Francis: The question is purely policy one, so should be postponed. Pasi: IKEv2 NAT-T never does RR for any addresses. Tero: True, but the problem is self-fixing in IKEv2 because the correct address is restored when some more traffic comes through. Pasi: Not if the attacker is the real client. Tero: This is the problem Francis was describing. ["3rd party bombing" --secretary] Charlie Perkins: If the address is dynamically allocated, you have to keep track of lifetime info. Tero: Yes, but the other end doesn't know the lifetime. -------------------- Jari Arkko (2005-03-30): We had an excellent discussion about most of the open MOBIKE issues in Minneapolis. The chairs would now like to run through the issues on the list, get even those not in the meeting involved, and attempt to come to a conclusion on each issue. Meeting slides are at http://www.vpnc.org/ietf-mobike/Minneapolis-05/ietf62_mobike_design.ppt We are starting with issues 18, 15, 6 in this e-mail. I'll summarize the meeting results on these issues, and state what the current working assumption appears to be. We 'd like determine what the final consensus is in two weeks, on April 13th, so please post your opinions as soon as possible so that we have time to complete the discussion. As usual, we'd like to get positive confirmation of a result rather than interpreting silence as agreement. So even if you don't have a problem with what is being proposed, it would be good to send an e-mail to the list saying that you are OK with the a particular a solution. So, issues 18, 15, and 6 are all related to if, when and how to do return routability tests. These are the primary defense mechanism against so called third party flooding attacks, where (perhaps a legitimate) party in the communication directs a stream of payload packets towards a victim. Note that flooding attacks are always possible, if not otherwise then by sending packets to the victim directly. The only remaining question is whether you can get some amplification out of this, e.g., by redirecting a stream that dies slowly when acks are not coming back. We don't need to do any better than what existing Internet already offers; we just need to ensure that we don't make the problem worse. We have already decided issue 6, which was about what kind of tests to use. The decision was to use a cookie-based approach, where the responding party can not fake the response unless he sees the original request. We are not re-opening that discussion. Issues 18 and 15 remain open. Issue 18 is about whether to include the tests at all, and issue 15 is about when to do them. The proposal that was discussed in IETF-62 was that it would be mandatory for a responding party to respond to an RR test (of course!), and that the initiation of an RR test would be configuration driven with default being "on". We had a discussion of whether to include also some indication of addresses in the certificates in this decision, and there seemed to be opinions on both sides. In any case, the standing proposal seems to be - Do the tests if configuration tells you to - Default is on - If the specific IP address can be found in the peer's certificate, you can skip the test Issue 18 is about when to do the tests, before or after you have moved the payload traffic stream. Again there seemed to be opinions on both sides. Before is more secure, after is faster. OTOH, in situations where you have well-behaving peers, as in most VPNs the efficiency may not be an issue if you turned this feature off to begin with. The proposal on the slides was - Do the tests before moving the payload stream. Let us know if these proposals work for you or if a different approach is needed. -------------------- Jari Arkko (2005-05-29): We are now closing issue 6 with the following text: > Here's a more detailed text proposal: "By default, > return routability test is done before moving the > traffic. However, [as decided in issue 18] these tests > are optional. Nodes MAY also perform these tests upon > their own initiative at other times." --------------------