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
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Be
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
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
At 3:55 PM +0300 4/3/09, Tero Kivinen wrote:
>Btw, is there any reason why [V+] is not listed in the IKE_AUTH
>excghange with EAP in the intermediate EAP messages and final AUTH
>request from the initiator?
We could add it, but I think that would surprise some implementers. Is it
really needed?
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
[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
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 r
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 delet
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
me
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 give
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 roun
Hi Matt,
Please see Sec. 1.3.3 of draft-ietf-ipsecme-ikev2bis-02. I believe it
answers your question.
Thanks,
Yaron
_
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Matthew Cini Sarreo
Sent: Friday, April 17, 2009 14:48
To: ipsec@ietf.org
Hi Matt.
You can't initiate INFORMATIONAL exchanges before the IKE_AUTH exchange(s)
concluded successfully.
Section 2.3 prohibits sending INVALID_MESSAGE_ID in responses, so you don't use
that for the IKE_AUTH exchange.
If the IKE_AUTH exchange contains invalid message IDs, these requests MUS
Below.
> -Original Message-
> From: Yoav Nir
> Sent: Monday, April 20, 2009 10:30
> To: Vijay Devarapalli
> Cc: Yaron Sheffer; IPsecme WG
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
>
> Hi
>
> Come to think of it, I'm wondering about something else.
>
> Let
Hi
Come to think of it, I'm wondering about something else.
Let's suppose that the gateway cannot tell where the user should connect. The
EAP exchange with the AAA server begins. The AAA server realizes that the user
name ("jdoe") is not in its database, and the user should be redirected to
ga
If an implementation decides to send the INVALID_MESSAGE_ID
notification, shoild it ONLY send this after an IKE_AUTH exchange has
been completed? It seems to be so as section 2.3 states that an
INFORMATIONAL exchange is started, but it is not clear what should be
done if a message of the two initia
16 matches
Mail list logo
