Narayanan, Vidya writes:
The requirement is quite simple and you just seem to ignore it or
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
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
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
Lakshminath Dondeti writes:
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.
Good advice, but that consensus process is from elsewhere. Not every
...@ietf.org] On Behalf
Of Tero Kivinen
Sent: Thursday, April 23, 2009 6:50 AM
To: Dondeti, Lakshminath
Cc: IPsecme WG; Paul Hoffman
Subject: Re: [IPsec] Issue #98: 1 or two round trips for resumption
Lakshminath Dondeti writes:
MOBIKE assumes that the other side has state, correct?
Yes
On 4/23/2009 7:19 PM, Tero Kivinen wrote:
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,
On 4/22/2009 4:11 PM, Tero Kivinen wrote:
Lakshminath Dondeti writes:
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.
How do you know this?
Because 10ms-100ms is MUCH less than 10
Lakshminath Dondeti writes:
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?
Yes.
Both solve the same problem that IKE SA recovers from the IP-address
change, or switching from one network to
On 4/23/2009 3:57 PM, Tero Kivinen wrote:
Lakshminath Dondeti writes:
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?
Yes.
Both solve the same problem that IKE SA recovers from the
On 4/21/2009 5:23 PM, Tero Kivinen wrote:
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.
Hi Tero,
How do you know this? I ask because, I would like to use those
arguments to tell people who are
Lakshminath Dondeti writes:
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.
How do you know this?
Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as
DHCP delays on WLAN
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 -
: 1 or two round trips for resumption
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
snip
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
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
On 4/20/2009 11:50 PM, Paul Hoffman wrote:
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
Of Paul Hoffman
Sent: Wednesday, April 08, 2009 10:56 AM
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
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
On Mon, Apr 20, 2009 at 11:20:55AM -0700, Paul Hoffman wrote:
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
a pointer to the second email
that supported removing the one RT exchange.
Thanks,
Vidya
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Paul Hoffman
Sent: Monday, April 20, 2009 10:16 AM
To: IPsecme WG
Subject: Re: [IPsec] Issue #98: 1
to the
gateway to decide.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
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
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
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
23 matches
Mail list logo
