Subject: [IPsec] Issue #98: 1 or two round trips for resumption

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Apr 2009 10:56:06 -0700

Greetings again. Tracker issue #98 is the same as the message that Pasi sent to the mailing list last month; see <http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.html>. There is disagreement among the authors of the session resumption draft how to deal with this issue.

One proposal is to add text similar to Pasi's to the document in order to let implementers understand all the things that they might need to do to prevent damage from a replay attack. If this is the method chosen, it should probably be as a section in the main body of the document, not as a "security consideration" because the issues are more operational than security.

A different proposal is to get rid of the one-round-trip mode and have the protocol always take two round trips. This prevents the attack that Pasi brings up, at a higher cost for the clients and server.

If you have a preference between these two proposal, please state it now. 

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Apr 2009 14:17:26 +0300

Paul Hoffman writes:
> Greetings again. Tracker issue #98 is the same as the message that
> Pasi sent to the mailing list last month; see
> <http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.html>.
> There is disagreement among the authors of the session resumption
> draft how to deal with this issue. 
> 
> One proposal is to add text similar to Pasi's to the document in
> order to let implementers understand all the things that they might
> need to do to prevent damage from a replay attack. If this is the
> method chosen, it should probably be as a section in the main body
> of the document, not as a "security consideration" because the
> issues are more operational than security. 
> 
> A different proposal is to get rid of the one-round-trip mode and
> have the protocol always take two round trips. This prevents the
> attack that Pasi brings up, at a higher cost for the clients and
> server. 
> 

This comes back to again to what use the resumption is aimed for (I
tried to ask this in meeting, and it seems nobody knows, so it makes
it impossible to think whether some optimization in the protocol is
needed or not).

Anyways, I would prefer to have safer protocol even if it would be one
more round trip. It would also make protocol simplier, as we would not
need to have separate optional cookie exchange version.

So I would vote for 2 round trip version of the protocol.

BTW the ticket #98 has wrong component (draft-ietf-ipsecme-ikev2bis),
it should have ikev2-resumption instead. Also the ticket component
names are not consistent, there is both ikev2bis and
draft-ietf-ipsecme-ikev2bis and only the last one of them is used,
but all other components ignore the draft-ietf-ipsecme part... 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Apr 2009 09:25:07 +0300

I prefer the second proposal.  I would rather have one (even if longer) variation of the protocol over two variations (even if one is shorter)

With such a possible attack published, auditors are going to force large installations to use the safer (and longer) version anyway, as it is up to the gateway to decide. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Hoffman
> Sent: Wednesday, April 08, 2009 8:56 PM
> To: IPsecme WG
> Subject: [IPsec] Issue #98: 1 or two round trips for resumption
> 
> Greetings again. Tracker issue #98 is the same as the message 
> that Pasi sent to the mailing list last month; see 
> <http://www.ietf.org/mail-archive/web/ipsec/current/msg04050.h
> tml>. There is disagreement among the authors of the session 
> resumption draft how to deal with this issue.
> 
> One proposal is to add text similar to Pasi's to the document 
> in order to let implementers understand all the things that 
> they might need to do to prevent damage from a replay attack. 
> If this is the method chosen, it should probably be as a 
> section in the main body of the document, not as a "security 
> consideration" because the issues are more operational than security.
> 
> A different proposal is to get rid of the one-round-trip mode 
> and have the protocol always take two round trips. This 
> prevents the attack that Pasi brings up, at a higher cost for 
> the clients and server.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
> 
Email secured by Check Point

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 13 Apr 2009 23:37:51 +0530

I prefer the first.  In terms of how to document it, we have examples of 
that already in IKEv2 spec.

On 4/12/2009 11:55 AM, Yoav Nir wrote:
> I prefer the second proposal.  I would rather have one (even if
> longer) variation of the protocol over two variations (even if one is
> shorter)
>
> With such a possible attack published, auditors are going to force
> large installations to use the safer (and longer) version anyway, as
> it is up to the gateway to decide.

Are you saying that currently large installations use the 6-message 
version of IKEv2?

thanks,
Lakshminath

>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Paul Hoffman Sent:
>> Wednesday, April 08, 2009 8:56 PM To: IPsecme WG Subject: [IPsec]
>> Issue #98: 1 or two round trips for resumption
>>
>> --Paul Hoffman, Director --VPN Consortium
>> _______________________________________________ IPsec mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/ipsec
>>
> _______________________________________________ IPsec mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Apr 2009 13:03:12 -0700

At 11:37 PM +0530 4/13/09, Lakshminath Dondeti wrote:
>Are you saying that currently large installations use the 6-message version of IKEv2?

Are you saying that the threat model for 1-round-trip session resumption are the same as for IKEv2 without cookies? If not, could you explain the above comment further?

--Paul Hoffman, Director
--VPN Consortium

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Apr 2009 09:30:50 +0530

I am saying they are similar (I wouldn't say they are the same, as they 
are two different protocols operating in different contexts).

regards,
Lakshminath

On 4/14/2009 1:33 AM, Paul Hoffman wrote:
> Are you saying that the threat model for 1-round-trip session
> resumption are the same as for IKEv2 without cookies? If not, could
> you explain the above comment further?
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Apr 2009 10:15:55 -0700

<co-chair hat on>

Greetings again. Of the people who replied, two favored mandating two round trips, and one favored keeping the current one round trip. That (anemic) result, plus the comment that lead to this thread, leads me to say that we need to change draft-ietf-ipsecme-ikev2-resumption to require two round trips.

Draft authors: please prepare a -03 with only the two-round-trip solution, and pull out the text about the one-round-trip option.

If someone really objects to this, please prepare a personal Internet Draft that lists exactly how you would change the current -03 draft to cover all the security issues that were brought forward.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 20 Apr 2009 23:15:53 +0530

Paul,

Before the one roundtrip mechanism is deleted, could you summarize how 
the security issue that was raised is applicable under the threat model 
we work with?  Let me help you out.  It is not really applicable.  Here 
is why:

RFC 3552 says that "While it is not a requirement that any given 
protocol or system be
    immune to all forms of attack, it is still necessary for authors to
    consider as many forms as possible.  Part of the purpose of the
    Security Considerations section is to explain what attacks are out of
    scope and what countermeasures can be applied to defend against them.
    In"

That poorly written and poorly edited RFC (notice the dangling "In") is 
all we have as guidance unfortunately.  What it does say is that it is 
perfectly fine to specify what attacks are out of scope.  We cannot have 
someone noting that "auditors" will force large installations to do this 
or that and have that dictate using a grossly inefficient resumption 
protocol!  It begs that questions of who those auditors are, what 
jurisdiction they are operating under and assuming what threat model?

The IKEv2 RFC really defines what is in scope.  Server state exhaustion 
attacks are not in scope for being mandatorily made "more difficult" for 
some definition of more.

Finally, if we don't like options, we are in the wrong standards body! 
When we design a security protocol for a variety of threat models and 
performance constraints, we are bound to have options.

Thank you.

best regards,
Lakshminath

On 4/20/2009 10:45 PM, Paul Hoffman wrote:
> <co-chair hat on>
>
> Greetings again. Of the people who replied, two favored mandating two
> round trips, and one favored keeping the current one round trip. That
> (anemic) result, plus the comment that lead to this thread, leads me
> to say that we need to change draft-ietf-ipsecme-ikev2-resumption to
> require two round trips.
>
> Draft authors: please prepare a -03 with only the two-round-trip
> solution, and pull out the text about the one-round-trip option.
>
> If someone really objects to this, please prepare a personal Internet
> Draft that lists exactly how you would change the current -03 draft
> to cover all the security issues that were brought forward.
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Apr 2009 11:20:55 -0700

At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote:
>Before the one roundtrip mechanism is deleted, could you summarize how the security issue that was raised is applicable under the threat model we work with?

No, I can summarize it after it is deleted, given that I deleted it in my last message.

The security issues that Pasi sent to the mailing list over a month ago include:

- A replay of a ticket can cause exhaustion of many resources, not just CPU or state on the gateway. Pasi listed these about a month ago.

- A replay of a ticket can cause a legitimate resumption to fail, depending on the algorithms used in the IKE SA.

This is unrelated to your, um, interesting logic about RFC 3552. The WG can decide its threat models as it sees fit.

>The IKEv2 RFC really defines what is in scope.  Server state exhaustion attacks are not in scope for being mandatorily made "more difficult" for some definition of more.

I don't see anything in RFC 4306 that limits the scope of the threat models for extensions.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 21 Apr 2009 00:38:10 +0530

On 4/20/2009 11:50 PM, Paul Hoffman wrote:
>> Before the one roundtrip mechanism is deleted, could you summarize
>> how the security issue that was raised is applicable under the
>> threat model we work with?
>
> - A replay of a ticket can cause exhaustion of many resources, not
> just CPU or state on the gateway. Pasi listed these about a month
> ago.

That was some interesting logic based on a fictional deployment.  Are we 
to optimize specifically for Pasi's vision of deploying networks?

>
> - A replay of a ticket can cause a legitimate resumption to fail,
> depending on the algorithms used in the IKE SA.
>
> This is unrelated to your, um, interesting logic about RFC 3552. The
> WG can decide its threat models as it sees fit.

Huh, and presumably without ever documenting such a threat model!

>
>> The IKEv2 RFC really defines what is in scope.  Server state
>> exhaustion attacks are not in scope for being mandatorily made
>> "more difficult" for some definition of more.
>

So, are you suggesting that we design IKEv2 for one threat model and 
IKEv2 session resumption for another?

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 20 Apr 2009 12:51:52 -0700

Considering that I didn't know what "now" meant and this message didn't have a deadline, I hope my input is considered.  I prefer the first option - we need to document the associated threat model with each assumption, but, deployments need to figure out what their threat model is.  The one RT resumption mechanism is key for handoff situations and for certain environments, it doesn't allow new attacks that are feasible outside of the IPsec use anyway.  If we threw out this model, we will be preventing a whole class of use cases that could otherwise use this resumption mechanism.  

Note that for these use cases, it is not much more expensive to just do the DH and use regular IKEv2, instead of using resumption, if the latter also involved as many roundtrips. 

Thanks,
Vidya 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Hoffman
> Sent: Wednesday, April 08, 2009 10:56 AM
> To: IPsecme WG
> Greetings again. Tracker issue #98 is the same as the message that Pasi
> sent to the mailing list last month; see <http://www.ietf.org/mail-
> archive/web/ipsec/current/msg04050.html>. There is disagreement among
> the authors of the session resumption draft how to deal with this
> issue.
> 
> One proposal is to add text similar to Pasi's to the document in order
> to let implementers understand all the things that they might need to
> do to prevent damage from a replay attack. If this is the method
> chosen, it should probably be as a section in the main body of the
> document, not as a "security consideration" because the issues are more
> operational than security.
> 
> A different proposal is to get rid of the one-round-trip mode and have
> the protocol always take two round trips. This prevents the attack that
> Pasi brings up, at a higher cost for the clients and server.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 21 Apr 2009 00:12:30 +0300

[As a coauthor of this draft:]

Hi Vidya,

Can you please give a more detailed description of this use case, where:

- The gateway doesn't care about CPU consumption, to the extent where it
doesn't mind the extra DH+RSA operations for thousands of simultaneously
arriving clients, and,
- The number of round trips until something useful happens (e.g. user
interaction) is so low that our 1 extra RT becomes critical.

Thanks,
	Yaron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Narayanan, Vidya
> Sent: Monday, April 20, 2009 22:52
> To: Paul Hoffman; IPsecme WG
> Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption
> 
> Considering that I didn't know what "now" meant and this message didn't
> have a deadline, I hope my input is considered.  I prefer the first option
> - we need to document the associated threat model with each assumption,
> but, deployments need to figure out what their threat model is.  The one
> RT resumption mechanism is key for handoff situations and for certain
> environments, it doesn't allow new attacks that are feasible outside of
> the IPsec use anyway.  If we threw out this model, we will be preventing a
> whole class of use cases that could otherwise use this resumption
> mechanism.
> 
> Note that for these use cases, it is not much more expensive to just do
> the DH and use regular IKEv2, instead of using resumption, if the latter
> also involved as many roundtrips.
> 
> Thanks,
> Vidya
>

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Apr 2009 17:01:21 -0500

On Mon, Apr 20, 2009 at 11:20:55AM -0700, Paul Hoffman wrote:
> >how the security issue that was raised is applicable under the threat
> >model we work with?
> 
> just CPU or state on the gateway. Pasi listed these about a month ago.
> 

Can a replay cache help?

Note though that getting replay caches to perform well is hard.  Ask any
Kerberos V implementor.

Nico
--

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 20 Apr 2009 18:23:57 -0700

Hi Yaron, 
We are going back to revisiting consensus here and re-explaining the use cases and I'd certainly like to keep this to as minimum a revisit as possible.  The use cases go back to what has been documented in the problem statement we published a while back - draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you should be still able to get to the draft.  

As a key point, I'll note that the situation where resumption is used here is a handoff case for a particular client and does not involve all clients connecting at once, where DH could be a problem.  And, in these cases, there is no user interaction involved - the mobile devices are doing everything they can to make handoffs seamless and work with no user or even application involvement.  

If you are only worried about the case of simultaneous reconnection of thousands of nodes, you can feel free to always use the 2-RT method in your gateway implementation - I am pointing out that it is not the universally applicable use case.  And, in most cellular deployments, IPsec is used for untrusted access networks (e.g., WLAN), while the DHCP servers and AAA servers are accessible from other access networks as well.  And, a handoff from cellular to WLAN needs to be seamless - you can envision an IPsec SA being set up all the time, but only resumed and actively used after you handoff to WLAN.  

I really don't fancy the "one threat model fits all" solution, since we cannot claim to envision all the use cases that will arise tomorrow, even if we manage to find a way to fit this one model for existing use cases.  And, in this case, we can't even fit it for existing use cases - so, let's document the applicable threat model and move forward. 

Vidya

> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Monday, April 20, 2009 2:13 PM
> To: Narayanan, Vidya; Paul Hoffman; IPsecme WG
> Subject: RE: [IPsec] Issue #98: 1 or two round trips for resumption
> 
> Pasi
> order
> have
> > > If you have a preference between these two proposal, please state
> it
> > > now.
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 20 Apr 2009 21:19:34 -0700

Hi Paul,
For my clarification, could you please state who are the people on each side of this? I've gone through all emails I have on this thread and I only see Yoav's email supporting the second approach.  It is entirely possible that my email isn't working as it should - but, I'd appreciate a pointer to the second email that supported removing the one RT exchange.  

Thanks,
Vidya

> Sent: Monday, April 20, 2009 10:16 AM
> To: IPsecme WG
> (anemic) result, plus the comment that lead to this thread, leads me to
> say that we need to change draft-ietf-ipsecme-ikev2-resumption to
> require two round trips.
> 
> Draft that lists exactly how you would change the current -03 draft to
> cover all the security issues that were brought forward.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 20 Apr 2009 22:11:10 -0700

Replying to my own email to note that I did receive the clarification offline from Yaron - it did turn out that my email was not picking up all elements of the mail thread properly.  

Thanks,
Vidya

> Of Narayanan, Vidya
> Sent: Monday, April 20, 2009 9:20 PM
> For my clarification, could you please state who are the people on each
> side of this? I've gone through all emails I have on this thread and I
> only see Yoav's email supporting the second approach.  It is entirely
> possible that my email isn't working as it should - but, I'd appreciate
> a pointer to the second email that supported removing the one RT
> exchange.
> 
> Thanks,
> Vidya
> 
> to
> to

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2009 14:53:00 +0300

Narayanan, Vidya writes:
> Hi Yaron, 
> We are going back to revisiting consensus here and re-explaining the
> use cases and I'd certainly like to keep this to as minimum a
> revisit as possible.  The use cases go back to what has been
> documented in the problem statement we published a while back -
> draft-vidya-ipsec-failover-ps-02 - it is now expired, but, you
> should be still able to get to the draft.

>From the ipsecme charter:

     Failover from one gateway to another, mechanisms for detecting
     when a session should be resumed, and specifying communication
     mechanisms between gateways are beyond the scope of this work
     item.

Thus failover from one gateway to another is outside the scope of this
document. If I remember right most of the use cases in
draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not
resumption use cases.

> As a key point, I'll note that the situation where resumption is
> used here is a handoff case for a particular client and does not
> involve all clients connecting at once, where DH could be a problem.
> And, in these cases, there is no user interaction involved - the
> mobile devices are doing everything they can to make handoffs
> seamless and work with no user or even application involvement.
> 
> If you are only worried about the case of simultaneous reconnection
> of thousands of nodes, you can feel free to always use the 2-RT
> method in your gateway implementation - I am pointing out that it is
> not the universally applicable use case.

>From the abstract of the resumption document:

   To re-establish security associations (SAs) upon a failure recovery
   condition is time consuming especially when an IPsec peer (such as a
   VPN gateway) needs to re-establish a large number of SAs with various
   end points.  A high number of concurrent sessions might cause
   additional problems for an IPsec peer during SA re-establishment.

So at least it was seen as important use case, and is thats why
included in the abstract (and the ipsecme charter text). 

> And, in most cellular deployments, IPsec is used for untrusted
> access networks (e.g., WLAN), while the DHCP servers and AAA servers
> are accessible from other access networks as well. And, a handoff
> from cellular to WLAN needs to be seamless - you can envision an
> IPsec SA being set up all the time, but only resumed and actively
> used after you handoff to WLAN.

Hmm.. This is again something completely different what I tought for
what the resumption protocol is supposed for. For example for this use
it would be useful to have have some way to force deletion of the
state from the server, i.e. say that this IKE SA is now going to go to
sleep, so you can remove the state, and there is no need to do dead
peer detection on it. The current protocol do not have anything like
that, and if you delete IKE SA you also delete the ticket, so that
mechanism cannot be used for that.

I still do not think making the 1 RT protocol to 2 RT protocol in that
case would really cause any noticeable effect to the actual handover.
Especially as you still most likely have the cellular network there to
be used, while you are doing DHCP + IKE_SESSION_RESUME etc on the
WLAN, thus only thing that is affected is that traffic moves 100ms
later from cellular to WLAN.

On the other hand security problems are big issue, as you most likely
try to IKE_SESSION_RESUME exchange over any WLAN you happen to see,
thus you effectively broadcast your tickets to attackers at will, so
attackers can simply take those tickets and sent them to server and
get your session resumed, but not forward any other traffic. Also any
firewall allowing port 500 packets out but not in, will cause similar
effect, as you will not get reply back, but server will consume your
ticket.

That case also brings out completely new issue which has not been
discussed before, i.e. whether the IKE_SESSION_RESUME must come from
the same IP-address than what was used before for the IKE SA, i.e. can
the IP-addresses change during the IKE_SESSION_RESUME. If that is
allowed, then what about NATs, i.e. is it allowed that even when there
was no NAT between hosts before, there is new NAT found during the
IKE_SESSION_RESUME?

Those are not covered by the current document, and at least something
MUST be said about those issues.

After this example use scenario, I am even more convinced that 2 RT
protocol is better and needed, especially if we do allow IP-addresses
change, and might need to do NAT-T detection on the IKE_SESSION_RESUME
exchange too. Allowing IP-addresses change means that the network
where the packets can come in, are different, meaning they might have
misconfigured firewalls or similars there, and killing your resumption
ticket by just trying to connect through broken firewall is bad idea.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 21 Apr 2009 15:46:29 +0300

Hi Tero,

To answer the last part of your mail, we always intended address change (and
presumably, NAT detection status change) to be supported. This should be
clarified in the document, and I have opened Issue #100 for this.

However, given that normal NAT detection happens during IKE_SA_INIT, can you
clarify why this would work better if we had a 2 RT protocol?

Thanks,
	Yaron

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, April 21, 2009 14:53
> To: Narayanan, Vidya
> Cc: Yaron Sheffer; Paul Hoffman; IPsecme WG

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Apr 2009 16:53:16 +0300

> > ticket by just trying to connect through broken firewall is bad idea.

I.e if you are always assuming the network is same, you do not need to
consider someone adding broken firewall in the middle. If on the other
hand you just happen to try every WLAN your client sees on its way,
there is most likely going to be few broken / misconfigured firewalls
/ NAT boxes etc on the way, and the 1 RT protocol will quite often use
your ticket, without you ever noticing it, as reply packets will not
reach you.

I.e. it is not really change required by the protocol, but the
operating environment changes to much more unreliable and untrusted,
meaning the protocol should be more robust against attacks.
-- 
[email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 21 Apr 2009 14:59:32 -0700

<snip>

> draft-vidya-ipsec-failover-ps-02.txt was specifically failover, not

This is really just a terminology issue.  Most of the use cases in that document are applicable to resumption.  In fact, the current solution for resumption is based on what was produced as a result of that problem statement (combined with Yaron's draft at the time), with the ability to exchange failover gateway candidates removed.  In other words, we are not handling anything specific to failovers, but, prior to this charter and WG, "failover" included resumption in the work we did. 

<snip> 

> included in the abstract (and the ipsecme charter text).

I'm not suggesting that it isn't important - just pointing out that it is not the only use case for resumption.   

> what the resumption protocol is supposed for. 

This has been discussed from the early days and I believe I've brought it up at almost every meeting, even at the last SFO session. As a contributor from the mobile side, this is my primary use case for the resumption work.  

> For example for this use
> peer detection on it. 

Good point - it would be nice to avoid having to do DPD on it and this would certainly be a useful feature if we wanted to consider it.  

> The current protocol do not have anything like
> be used, 

This is conjecture and not a fact.  And, I'd prefer to design for seamless, quick handoffs, not with an assumption that you have a second interface up. 

> while you are doing DHCP + IKE_SESSION_RESUME etc on the

And, btw, WLAN is only one type of untrusted network - other scenarios may be cellular-to-cellular handoffs in roaming scenarios, cellular to WiMAX handoffs, etc. In some of these cases, there are even RF limitations if you are using a single radio, multi-mode chipset.  I'd prefer that we keep the discussion on the RF systems itself out and see what best we can do with our protocols. 

> effect, as you will not get reply back, but server will consume your

Obviously, the firewalls need to be handled properly if the operator wants this to work - so, that is not the primary issue.  I don't understand what you mean by "not forward any other traffic" in your description of the attack.  The attacker does not have the keys to decipher any of the actual packets. The only thing the attacker can do is replay a ticket *after* it has already been sent by the client - in this case, we already talked about some limited backend state the gateway can maintain to limit the impact due to replays.  It is also important to note that the other backend entities (which was Pasi's main concern) are accessible through the so-called "trusted networks" that often arguably have a reduced degree of security than the IPsec case.   

> the IP-addresses change during the IKE_SESSION_RESUME. 

The protocol does allow for IP address changes and also allows the client to request a new IP address from the gateway for its internal IP address - do you see a reason why this doesn't work? 

> If that is

As Yaron indicated, NAT traversal will work here. And, designing for broken firewalls and NATs as the primary case seems strange.  

> MUST be said about those issues.

Sure, adding text for these in a more explicit fashion would be fine.  

> ticket by just trying to connect through broken firewall is bad idea.

I don't understand why you need 2 RTs to account for IP address changes or NAT-T.  As I said, I don't want to design for broken firewalls as the primary case - if there are broken firewalls, things may be slower, but, I don't buy the argument that things should always be slower to account for possible broken firewalls. 

Vidya

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 22 Apr 2009 12:18:51 +0530

Hi Tero,

How do you know this?  I ask because, I would like to use those 
arguments to tell people who are experts in handovers that multiple RTs 
don't matter.

> On the other hand security problems are big issue, as you most likely
How do we know that they are a "big" issue?  Do we expect these systems 
to be under attack most of their operational life?
> effect, as you will not get reply back, but server will consume your
Even if this happens, the payoff for the attacker is very little since 
the legitimate parties can always establish another connection.  The 
quality of experience would be bad because another session needs to be 
established when under attack, but at the cost the attacker has to pay, 
one might even say that this is not even a serious threat.

I really would liked to be convinced that I am wrong here, but I see 
this to be a quite moderate or low risk attack.

thanks,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Apr 2009 12:23:26 +0300

Narayanan, Vidya writes:
> This is really just a terminology issue.  Most of the use cases in
> that document are applicable to resumption.  In fact, the current
> solution for resumption is based on what was produced as a result of
> that problem statement (combined with Yaron's draft at the time),
> with the ability to exchange failover gateway candidates removed.
> In other words, we are not handling anything specific to failovers,
> but, prior to this charter and WG, "failover" included resumption in
> the work we did.

Main thing between resumption and failover is that resumption assumes
you reconnect back to same host, as in failover you can reconnect to
another host. I myself consider resumption as subset of the failover
cases, i.e. failover cover more things than what resumption itself
covers.

Note, that charter explictly mentions that the resumption can also be
to the cluster of closely cooperating gateways, but cooperating
protocols inside that cluster are not part of the our scope.

> And, btw, WLAN is only one type of untrusted network - other
> scenarios may be cellular-to-cellular handoffs in roaming scenarios,
> cellular to WiMAX handoffs, etc. In some of these cases, there are
> even RF limitations if you are using a single radio, multi-mode
> chipset.  I'd prefer that we keep the discussion on the RF systems
> itself out and see what best we can do with our protocols.

With WLAN and so on I do not think the problem is the RF part, I think
it is the DHCP and so on part. For example in IETF it usually takes me
about 10 seconds to just to get DHCP address when I first time connect
to the network (for some reason it seems the servers always answer
only after 2-3 retries). I have not really seen WLAN networks that
offer anywhere near the subsecond connection times you seem to assume
here.

It might be true in the cellular-to-cellular handoffs, but do you
really use IPsec and resumption on such environments. I would expect
mobike would be much better used there, as if you need IPsec for one
cellular network, you might as well do it always. 

> Obviously, the firewalls need to be handled properly if the operator
> wants this to work - so, that is not the primary issue.

If you start to talk about WLANs, then you are not talking about
operators, you are talking about random basestations someone has set
up somewhere. I can assume network operators to configure their boxes
properly, I cannot really assume random home user for setting their
WLAN basestation properly.

> I don't understand what you mean by "not forward any other traffic"
> in your description of the attack. The attacker does not have the
> keys to decipher any of the actual packets.

The thing that makes replay attacks harder is that attacker does not
get the ticket he could replay. If you walk around on the street and
see some random WLAN named "open wifi" and your phone decides to see
if it works, and gets DHCP address, and after that tries resumption to
gateway, you just sent that ticket to attacker. Attacker will then
take that packet from the air, or from the basestation, and use it to
attack, i.e. after he takes that packet and sends it to gataway (for
example with fake source IP, so return packets never reach you), then
your ticket is killed, and your accounts billing started going.

> The only thing the attacker can do is replay a ticket *after* it has
> already been sent by the client - in this case, we already talked
> about some limited backend state the gateway can maintain to limit
> the impact due to replays.

Yes, after client sent the ticket, but that does not mean server ever
got that ticket from client. I.e if the "fake" WLAN is set up so it
will drop all UDP port 500/4500 packets, you never get any IPsec
resumption on that network, but you still assume your ticket is valid
as for your point of view it was never used. The attacker can see that
ticket, and can then mount the attack.

Or it could be that the WLAN is set up to allow any UDP packets out,
but only "known" UDP packets in (dns and nothing else). In this case
you yourself make the attack, i.e. you kill your ticket by sending it
to the server, but server's reply never reaches you, so you still
think you have not used the ticket, but server has done that. 

> The protocol does allow for IP address changes and also allows the
> client to request a new IP address from the gateway for its internal
> IP address - do you see a reason why this doesn't work?

Other than the fact that draft does not mention it, no. As an
implementor, I would add checks that IP address must be same, as there
is no mention that IP-addresses could change. Also I would not send
NAT detection payloads, as they are not mentioned in the draft.

If such feature is wanted, it MUST be specified in the document too.
Do not assume implementors guess correctly. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Apr 2009 13:41:30 +0300

Lakshminath Dondeti writes:
> How do you know this?

Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as
DHCP delays on WLAN networks. And there is already way to do that in 1
RT protocol, i.e. MOBIKE. With MOBIKE you can recover the changing of
the network or IP-address in 1 RT.

Resumption should not really be used for that.

Resumption means that something caused the IKEv2 SA in the client to
removed, without telling that to the server, and thats why client
decided to use resumption instead of just continuing using the IKEv2
SA it has up and running.

If we take the network outage example from the charter, the duration
of network outage is usually MUCH, MUCH longer than the 2 RTs required
to reconnect to the server.

> I ask because, I would like to use those arguments to tell people
> who are experts in handovers that multiple RTs don't matter.

Tell them to use correct protocol on correct places. If they want
subsecond recovery from the handover from one network to another, they
should use MOBIKE, and keep the IKEv2 SA up all the time (Altough even
with MOBIKE it usually takes several seconds for the nodes to actually
react that they have lost connectivity, and needs to start corrective
actions, but if we assume subsecond recovery is required, then we can
also assume the network can immediately tell when recovery actions are
required).

> the legitimate parties can always establish another connection.

No, he does not, as if he was trying to do handover from cellular to
WLAN, he would simply continue using cellular in that point, but the
accounting for example would be enabled for both (i.e. for servers
point of view he is using WLAN and cellular simulatenously, from
clients point of view he using only cellular).

Again then when he finally gets WLAN which works, he suddenly have 3
RT protocol to use (trying resumption, failing that, and falling back
to full IKE) with user authentication, and possibly even user
interaction.

> The quality of experience would be bad because another session needs
> to be established when under attack, but at the cost the attacker
> has to pay, one might even say that this is not even a serious
> threat.

Making the user to do user interaction by simply sniffing one packet
from the air, and forwarding it to the right server is very cheap way
to annoy people...

For users point of view it does not even look he is under attack, he
just sees that this crappy network again requires him to
reauthenticate at random times. Note, that he does not blame the
attacker's network, as he didn't detect anything there. The attack can
have happened hours before, and then when he finally comes to the home
WLAN network, or some other network which actually works, he sees that
he needs to reauthenticate. 
-- 
[email-masked]

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 23 Apr 2009 12:30:14 +0530

> the network or IP-address in 1 RT.
The 10seconds are not a barometer.  So, 1 RT will be closer to the 10ms 
than the 2 RT, which is better, so I am not sure how you figure it is 
not noticeable.  If someone is in a call, the 2 RT adds to the latency.
> also assume the network can immediately tell when recovery actions are
When did MOBIKE come into picture?  What are you saying Tero, that IPsec 
session resumption is an alternative to MOBIKE and a slow one at that?
> from the air, and forwarding it to the right server is very cheap way

"Annoy" being the keyword.  I am now more convinced that we are really 
making the protocol inefficient because some kid might try to annoy some 
people some time.  To counter such potential annoyances which may not 
happen at any frequency that matters, we are going to sacrifice the user 
experience all the time?  I fail to understand this line of reasoning.  
What am I missing?

thanks,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Apr 2009 13:27:48 +0300

> session resumption is an alternative to MOBIKE and a slow one at that?

Yes.

Both solve the same problem that IKE SA recovers from the IP-address
change, or switching from one network to another (i.e. from cellular
to WLAN).

I do not really see any fundamental reason why the IKE SA needs to be
taken down when in cellular. I can see reasons why it might not be
needed, but the IKE SA could still be kept up and running, and if done
that way, then MOBIKE will offer solution how to move the IKE SA to
the new network, and it will mostly do it in 1 RT.

> experience all the time?

I am saying we are not sacrificing the user experience in any
noticeable way even if we do 2 RT protocol. I expect that 99.999%
users will never notice whether the 1 RT or 2 RT protocol was used if
there is no attack. On the other hand, 100% users will notice the
attacks if 1 RT protocol is used, and 0% of users will notice the
attacks if 2 RT protocol is used.
-- 
[email-masked]

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 23 Apr 2009 16:40:18 +0530

> the new network, and it will mostly do it in 1 RT.
MOBIKE assumes that the other side has state, correct?  Session 
resumption has to do with providing that state.  How are they the same?
> attacks if 2 RT protocol is used.
Under attack, the protocol stretches to 3 RTs.  So, you are saying that 
there is no noticeable difference between 1 and 2 RTs, but there is 
between 2 and 3?  Is your point that the DH computation will be noticed?

My point is that we'd beyond the real-time budgets after 1 RT anyway.  
Now of course, to prove any of this (as opposed to your word against 
mine), we have to workout test scenarios and the like and measure user 
perception (we can throw in 5 9's all we want, but people spend millions 
on real perception testing).  All I am asking for is for the group to 
realize that there are cases where the budgets are low and therefore 
allow the 1 RT exchange.

regards,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Apr 2009 16:49:33 +0300

Lakshminath Dondeti writes:
> MOBIKE assumes that the other side has state, correct?

Yes. 

> Session resumption has to do with providing that state. How are they
> the same?

In this example given (handover from cellular to wlan, without
breaking existing phone call), I do not really see any point why the
IKE SA state needs to be removed from the server side, and as such I
think the much better solution is to use MOBIKE and keep IKE SA up all
the time.

As I do not have any idea where people want to use the resumption, I
have VERY HARD time to justify the different protocol options. But
anyways one of the things required is that it "shall not have negative
impact on IKEv2 security features", and I think 1 RT protocol will
have negative impact to security features.

> Under attack, the protocol stretches to 3 RTs.

3 RT + Diffie-Hellman + public key operation + user interaction to
type in password or securid token etc.

> So, you are saying that there is no noticeable difference between 1
> and 2 RTs, but there is between 2 and 3? Is your point that the DH
> computation will be noticed?

With group 18: yes... With typing in the passphase to do
reauthentication with RSA token card : yes. With digging out your
securid card and typing in pin, and typing in the next token to the
prompt: yes.

> My point is that we'd beyond the real-time budgets after 1 RT

You should not really do break-before-make style of transitions on
real-time environments, and if you keep the old connection while
making the new one, then this whole issue is non-issue.
-- 
[email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 24 Apr 2009 00:12:25 -0700

Somehow, we in the IETF think that we can make decisions for other standards bodies, especially ones that do real deployments.  I don't know how we can say things like they should always use the IKE SA whether they need it or not - there can be several reasons not to use it when they don't need it, including how some VPN vendors may charge.  Also, mobility may need to be handled by MIP6 and we know that it doesn't co-exist with MOBIKE.  

I'm also further intrigued by this attack we are so passionately discussing - the motivation for the attacker here is to annoy other users?   Surely, the attacker gets nothing meaningful in return - I simply can't see how the risk of such an attack can be anywhere close to even medium - it is barely low in my view.  The reward for the attacker in return for the work is non-existent - if someone can steal spectrum or otherwise get Internet access for free or get access to other users' credentials, etc., it is worth discussing and protecting against.  In this case, I'd say that we've already spent more time discussing it than it is worth it.  

Vidya

> Of Tero Kivinen
> Sent: Thursday, April 23, 2009 6:50 AM
> To: Dondeti, Lakshminath
> Cc: IPsecme WG; Paul Hoffman

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 24 Apr 2009 15:16:09 +0530

> have negative impact to security features.
I fail to understand the "security" issue though in that the attack has 
already been identified as mere annoyance and does not result in any 
compromise.
> type in password or securid token etc.
Depends.  Some VPN clients do better than others and some require little 
to no user interaction.
> securid card and typing in pin, and typing in the next token to the
Same as above.  But the real point here is that under the attack 
scenario, the user has bad experience.  As long as the attack is 
categorized as low risk, we don't have to worry about this, do we?
> making the new one, then this whole issue is non-issue.
Good advice, but that consensus process is from elsewhere.  Not every 
device has multiple interfaces, not every architecture implements the 
idea of multiple simultaneous associations with base stations, and so on.

If our goal is to design for multiple different scenarios and if the 
attack is really not serious, I really don't see why we would rule out 1 
RT exchange.

regards,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 27 Apr 2009 14:58:48 +0300

Narayanan, Vidya writes:
> Somehow, we in the IETF think that we can make decisions for other
> standards bodies, especially ones that do real deployments.  I don't
> know how we can say things like they should always use the IKE SA
> whether they need it or not - there can be several reasons not to
> use it when they don't need it, including how some VPN vendors may
> charge.

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.

> 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?

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.

> I'm also further intrigued by this attack we are so passionately
> discussing - the motivation for the attacker here is to annoy other
> users?

Almost all DoS attacks are only there to annoy the users. If someone
uses DoS attack to bring some web server or dns-name server or similar
down for few hours, that is just annoying users. Everything will work
again when the attacks stops, and might even work during the attack
but access might be much slower than normally.

> Surely, the attacker gets nothing meaningful in return - I
> simply can't see how the risk of such an attack can be anywhere
> close to even medium - it is barely low in my view.

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.

And it is not only against protecting against the attacks, this is
also against normal working of the protocol. I.e. if sending one
packet whose response packets gets lost, can destroy state from the
server, in such way that client cannot detect that, and needs to start
IKE SA creation from the beginning, I consider even that a big
problem.

When we were specifying the MOBIKE we made sure it works also in cases
where some of the network connections are one-way, i.e. no return
packets get back. It consideres such links broken, and does not use
them. This was considered important to get it right, because in that
environment it was seen that quite often the links it might see might
have such unidirectional properties, and the whole protocol cannot be
broken because of one such link.

With resumption the whole protocol breaks down if such unidirectional
link is ever tried to be used.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 27 Apr 2009 15:03:30 +0300

> idea of multiple simultaneous associations with base stations, and so on.

We were discussing moving traffic from "secure" cellular network
(which do not require IPsec protection, and IKE SA was suspended
because of that) to "unsecure" WLAN network (which now requires IPsec
protection because it is unsecure). Do you really say some device
which can talk to both WLAN and cellular network cannot talk to both
of them simultaneously?

Even with if they cannot be used simultaneously they can still bring
the IKE SA up while using the cellular network, and then use MOBIKE to
move the already up and resumed IKE SA from cellular to WLAN.

It seems there is again some scenarios you are refering to that I do
not know about, as I do not really think you are now talking about the
same use case anymore. 
-- 
[email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Apr 2009 13:20:07 -0700

> protocol be weaker because of the requirements from those other

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 these cases, handoffs don't happen using a single radio operating in multi-mode.  

> 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.  

> 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>
 
> 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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Apr 2009 18:16:43 -0700

One correction below. 

> Sent: Wednesday, April 29, 2009 1:20 PM
> To: Tero Kivinen
> Cc: IPsecme WG; Dondeti, Lakshminath; Paul Hoffman
> 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

> 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.
> 
> 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>
> 
> 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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Apr 2009 13:53:51 +0300

> provide unacceptable alternatives.  The handoff latency must be good

What handoff? We are talking about resumption, not handoff. I do not
consider those same.

Or then I understand completely wrong what handoff is, and what
resumption is.

For me handoff is when you have active connection to one place, and
then you want to move that connection to another place without
interrupting the communications.

Resumption is when we have connection that was disconnected
temporarely because of some reason, and we want to resume it after
some period of time.

Their requirements are very different and if we are really making
standard for handoff, then our protocol would be different.

> 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.

I am not claiming it should be used all the time, but I am claiming
that if you are planning to start to use IPsec again you should not
first tear down your non-IPsec connection while you set up the IPsec
connection. You should keep the old connection alive and then when you
have IPsec connection ready, then you move your traffic to that
connection requiring IPsec.

I do not really belive you get very good handoff with break before
make methods on any networks. 

> 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).

They do not need to maintaing IPsec session for all devices for all
time, they need to resume them about 10-100ms before they are actually
required, i.e. before they break their old connection.

One dropped packet on the IPsec resume is going to cause several times
longer delay than one round trip.

It is bed idea to design system so it does not tolerate even single
lost packet. 

> 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 these cases, handoffs don't happen using
> a single radio operating in multi-mode.

Then when you decide you are going to roam to network that requires
IPsec, you can resume the IPsec connection using the old connection
(even when it is unneeded there), and then you have IPsec connection
which you can move to new network with single round trip protocol.

With WiFi the network setup time is usually much longer than one round
trip. In devices I normally use (laptop, pda etc) the device requires
about 3-10 seconds to get network up and working (turning radio on,
finding basestation, connecting to basestation, getting IP-address via
DHCP etc). I have not ever seen wlan that would work so fast that it
would be enough for VoIP handoffs.

I do not know about WiMAX, but at least my 3G cellular phone usually
takes about 1-2 seconds to create data connection (i.e. when I select
which "internet" connection to use to the time when it actually starts
loading the page) and it seemed to take about one more second before
the packet it sent out actually reaching my server.

Adding 20-40 ms for one more round trip time to that does not really
affect the big picture. On the other hand if you can do network setup
while still keeping old connection alive, then you can also do the
resumption and the one round trip during that time too.

Can you explain me on what kind of devices you can really do handoff
to new network with break and make method?

> functionality and also conflicting with it if it ran together.

When using MOBIKE you should not use the K-bit (if that is what I
think it is), but you should just leave the IP-address handling of the
IKE and IPsec to MOBIKE.

The MOBIKE was meant to be used as building tool for MIP6, i.e. it
still requires MIP6 to start using it, i.e. there should have been
separate document specifying how to use MOBIKE and MIP6 together.

It never assumed it would solve the MIP6 problem directly, it assumed
that MIP6 and MOBIKE could together be used to solve the problem.

> Please read the thread on "MOBIKE and MIP6" on the MIP6 mailing list
> from back in 2006 if you are interested in more details.

I have not really been interested in MIP6, after I showed them how
MIP6 and IPsec can easily used together without any modifications to
either MIP6 or IPsec, but they said that solution was not what they
specified, so they are not going to use it (and that solution
presented at that time, would work perfectly with MOBIKE now).

> The conclusion was that a scenario of using MOBIKE and MIP6 between
> the same two endpoints must be avoided.

So I assume nobody has yet specified how to use MIP6 and MOBIKE
together, but instead MIP6 still want to use their modified version of
IPsec?

> 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.

Charter or draft does not say anything about resumption to be aimed
for mobility use cases. I do not say it should not be one possible use
case, but again it is hard to decide which optimizations to take when
we do not have common idea where this protocol is meant for.

As I still do not know where resumption is really meant for, I cannot
really say what kind of protocol it should be.

> 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.

And where can I find this "good threat analysis"?

As you did ignore my point that this sitution can happen also without
any attacker, by just in normal use with misconfigured networks. 

> If the incentive doesn't exist or is not meaningful, the likelihood
> is generally low, causing the attack to be of low importance.

It is really hard to imagine what kind of incentive could DoS
attackers have in general.

They could be just pissed of with some operator charging too much
money for their phone calls, and they could try to make that operators
networks perform badly. If the network is really set up using
break-before-make connections (which I still do not belive anybody
would really use), they can cause two drops by just first luring
network user to wrong network and stealing ticket, and second break
when network user tries to use the already consumed ticket later.

I.e. they just set up WLAN basestation sending out station id which
matches the operators allowed WLAN network. When user roams to that
network, it will not get connection at all, thus his phone call
breaks. User has still already sent out the ticket to the network,
which was stolen by the attacker, and attacker uses that ticket to
destroy the state from the SGW side.

Now when client moves back to cellular network (after detecting that
WLAN it tried to move to didn't offere serivce), everything works
fine, until it finally reaches the proper WLAN and tries to move to
that. Now the ticket is already used, and instead of the unacceptable
1 RT, he actually now have 3 round trips + Diffie-Hellman time, which
is by your definition unacceptable for VoIP handoffs.

Of course as attacker does not want to make active transmissions
himself, he will rather make virus attacking phones and pdas, which
will set up the attack, i.e turn on the WLAN on the phone and starts
faking to be basestation, and forwarding the ticket packets forward,
but dropping all others.
-- 
[email-masked]