-------------------- Pasi Eronen (2004-08-24): At the San Diego meeting I promised to create a new issue about the various threats the protocol should consider. So far, we have at least the following (notation: the IKE peers are A and B; C is an innocent victim). 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. 3) Unauthenticated attacker directs the traffic stream from B to somewhere (perhaps to the attacker or /dev/null), with the intent of preventing the legitimate peers from communicating. 4) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). Do we have any other threats, assuming we don't need to repeat those where MOBIKE doesn't change anything in normal IKEv2? Should we add some discussion about these to the design document and/or protocol proposals? (BTW, a comment about terminology: Francis has quite consistently called case 1 "transient pseudo-NAT attack" and case 2 "third party bombing". I (and several others) have sometimes called both 1 and 2 third party bombing.) -------------------- Francis Dupont (2004-08-30): I disagree a bit about the presentation: the level of authentication is very important too. With other words, we shall have to give to the return routability procedure(s) a trust level. .... 1 and 3 should be merged? ... if you have read my draft about case 1 you know why I has considered cases 1/3 as very different of case 2. BTW the attack and the defense are very bound to NAT traversal capability, when the case 2 is essentialy a question of trust in the peer (this is why the level of trust is so critical), and the name comes from MIPv6 security discussion (Erik or Jari?). -------------------- Atul Sharma (2004-09-02): Why are we in MOBIKE trying to solve "transient pseudo-NAT" attack? The problem is of general nature, and will impact IP, IPsec traffic as much as (MOB)IKE traffic. Any solution to this attack has to be of general nature rather than MOBIKE-specific solution just working for MOBIKE. Just trying to understand.... Actually, let me rephrase: I do not want to imply that "transient pseudo-NAT" attack has no relevance for MOBIKE. MOBIKE is all about authenticated management of (change of) address. And "pseudo-NAT" is about malicious change of address. So there is definite relevance there. The issue is that problem can be manifested in several scenarios other than just IKE. It may make sense to either do a general solution (else where?) or if we do MOBIKE-specific solution, we should let other affected working groups be made aware of it. -------------------- Jari Arkko (2004-10-11): I think we already agreed that (say) AH can be used to fight this in general. However, I wanted to make a couple of additional points. First, this type of packet modification vulnerabilities appear to come in two variants: those where you have to be a mitm during the beginning of a session vs. you can change the addresses at any time. I believe IKEv2 situation is of the latter type, as long as some NAT was discovered initially. Plain IP traffic is however typically of the former type: changing an address in a packet would not redirect a TCP stream in middle of a session. Secondly, the AH protection that Francis mentioned is obviously for "other" protocols and for payload packets. The protocol that creates the SAs for this protection can, however, also have the vulnerability. I think that's the issue that we are talking about here... -------------------- Jari Arkko (2004-10-11): I think we concluded in this threat that your original list of four threats should become three, by merging threats 1 and 3. Francis made the point that the level of authentication makes a difference. Mohan made the point that there's a difference between packet modification (on-path) vs. independent (off-path) attacks. Atul asked about the need for more general protection of the threat 1 than what can be done in MOBIKE; I think we concluded that AH or something similar is sufficient for other protocols but people wanted MOBIKE to provide security against the attack. Taking this all into account, I think we have: 1) Unauthenticated attacker directs the traffic stream from B to a third party C, with the intent flooding C with unwanted traffic. The attacker can be either on-path or off-path. The latter is of course more serious, but easier defended attack. 2) Authenticated peer A directs the traffic stream from B to a third party C, with the intent of flooding C with unwanted traffic. The "authenticated peer" is the one that performed the initial IKE authentication. A request to update an address could be either unauthenticated, authenticated but leaving the actual address vulnerable for MITM modification. The validity of the new address could either be implied by the request or be independently verified; this verification could again require either no authentication at all, full authentication, or participation of the authenticated peer but leaving the address part unprotected. 3) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). -------------------- Francis Dupont (2004-10-11): 3) Unauthenticated attacker causes the IKE_SA to be closed by modifying just one or two IKE packets (if attacker can modify all packets, he can of course DoS). => I have a concern with this because it is not a MOBIKE threat but an IKE one. I propose to rewrite it, adding for example that MOBIKE should not add a new vulnerability (i.e., MOBIKE should be as resillient as IKE, BTW this should be easy to do). -------------------- 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. -------------------- (Issue list editor's note: The issue numbers in Jari's email are wrong. Issue 15 was closed a long time ago. -------------------- Closed on 2005-05-16 with summary "Attacks by the authenticated peer will also be considered." --------------------