> > It is impossible for IETF to think about those other standard bodies, > as we do not know what they plan to do. I have several times tried to > get people to explain me the use case for which this protocol has been > aimed for, so I could think whether some specific attack or > optimization is suitable or not, but as only reply I have received is, > that it is outside the scope of this discussion, then there is really > no point of blaming people for making decisions for other standard > bodies. What else can we do? > > Nobody has still explained me why the 1 RT protocol is required for > those other standard bodies, and why should the security of this > protocol be weaker because of the requirements from those other > unknown standard bodies. >
The requirement is quite simple and you just seem to ignore it or provide unacceptable alternatives. The handoff latency must be good enough to support VoIP like applications and the handoff may imply needing an IPsec session between the mobile and a network entity (be it a VPN or for MIP6 channel security). You claim that in such scenarios, IPsec should be used all the time, even on the interfaces that don't require it for security purposes - so, even if the device is not running MIP6 until it moves to the new interface, it now needs to establish an IPsec session. However, this is not acceptable for various reasons (including that operators are not interested in maintaining IPsec sessions for all devices just in case it roams at some point). Also, designing for a fixed set of interfaces is a problem - it may not always be 3G and WiFi - it could be 3G and WiMAX; it could be 3G infrastructure and 3G Femto; it could be 3G infrastructure and 3G multi-hop, etc. In many of th ese cases, handoffs don't happen using a single radio operating in multi-mode. > > Also, mobility may need to be handled by MIP6 and we know that it > > doesn't co-exist with MOBIKE. > > That is news for me. One of the reasons MOBIKE was created was to > allow it to be used as building block for Mobile IP. So why does not > MIP6 and MOBIKE co-exits? We at least tried to make MOBIKE so it could > be used by Mobile IP, and there were Mobile IP people taking part in > the specification process back then. > > So what is the exact problem there? > The fundamental issue is that MIP6, using the K bit, allows the IP address on the IKE SA to change, thereby accomplishing the MOBIKE functionality and also conflicting with it if it ran together. Please read the thread on "MOBIKE and MIP6" on the MIP6 mailing list from back in 2006 if you are interested in more details. The conclusion was that a scenario of using MOBIKE and MIP6 between the same two endpoints must be avoided. Also note that as I mentioned above, there are scenarios where MIP6 doesn't kick off until a handoff occurs. > I am thinking it might not be worth of standardizing the resumption at > all, if we for that again hear 3 years after we finished the work that > it cannot be used because of some unspecified reason. > Well, the current approach for designing it for known air interfaces that some of us may be familiar with and some models where multiple interfaces need to simultaneously be active is certainly not going to help it. We might as well say that this is not meant for addressing the mobility use cases. <snip> > Most of the DoS attackers are not wanting to get something meaningful > in return. I still think we need to design protocols so they are > secure against such attacks. > I'm really surprised by this. A good threat analysis should determine the likelihood and impact of an attack and likelihood largely depends on the attacker's incentive. If the incentive doesn't exist or is not meaningful, the likelihood is generally low, causing the attack to be of low importance. NIST's Risk Management Guide goes through a good description of how to do a threat analysis and is useful. Simply protecting against attacks that we can all dream up, regardless of the threat model or motivations is not useful. Vidya _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
