One correction below. > -----Original Message----- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Narayanan, Vidya > Sent: Wednesday, April 29, 2009 1:20 PM > To: Tero Kivinen > Cc: IPsecme WG; Dondeti, Lakshminath; Paul Hoffman > Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption > > > > > 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. >
s/handoffs don't happen/handoffs happen > > > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
