On 7/30/09 1:36 AM, "Tero Kivinen" wrote:
> Vijay Devarapalli writes:
>> 7. Handling Redirect Loops
>>
>>The client could end up getting redirected multiple times in a
>>sequence, either because of wrong configuration or a DoS attack. The
>>
to change it "MAY", you might as well say nothing about it. A
sentence that says "These values MAY be configurable on the client" doesn't
say much. I would be fine with "SHOULD" instead of "MUST".
Vijay
>
>
> -Original Message-
> Fro
Hello,
During the IESG review of draft-ietf-ipsecme-ikev2-redirect, it was brought
up that the text about handling redirect loops should be in the main body of
the draft instead of the security considerations section. One of the ADs
also wanted some default values to detect a loop. Here is the mod
Hello,
The document was revised to address the comments received from the AD.
The diff is at
http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2-redirect/draft
-ietf-ipsecme-ikev2-redirect-11-from-10.diff.html
The Mobile IPv6-related text, that was in two different sections, has
been moved
Hi Pasi,
On 6/11/09 3:13 AM, "pasi.ero...@nokia.com" wrote:
> Vijay Devarapalli wrote:
>
>>> What do you mean by "valid"? So the client could potentially ignore
>>> the redirect (in the last IKE_AUTH response), and continue using the
>>&g
Hello Yaron, Tero,
Ok, I am fine with setting aside some space for private GW identity. Lets
set aside 240-255.
Since we have the private space, I guess we don't need the "locally
meaningful name" as a GW identity.
Vijay
On 6/11/09 2:00 AM, "Tero Kivinen" wrote:
> Yaron Sheffer writes:
>> Hi V
Hi Pasi,
On 6/5/09 4:42 AM, "pasi.ero...@nokia.com" wrote:
> Vijay Devarapalli wrote:
>
>>> And having these two cases is more complex than having just one
>>> (IKE_SA is not used for any more exchanges). What benefits does
>>> this additional com
can be assigned by "Expert Review" do we really need to set
aside space for private use? You can always request new assignments without
having to revise the RFC.
Vijay
>
> Thanks,
> Yaron
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mai
prietary protocol) that includes the gateway names (and how to find them -
> IP address or DNS name). These gateway names can optionally be shown to the
> user in the GUI. In any case, the client is as aware of the names as the
> gateways.
> ________
&
Hi Pasi,
On 5/28/09 10:38 AM, "pasi.ero...@nokia.com" wrote:
> Vijay Devarapalli wrote:
>
>> In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is
>> not valid is when EAP is used and the redirect is done based on the
>> unauthenticated ID. I
Hi Yoav,
On 5/27/09 3:11 AM, "Yoav Nir" wrote:
> OK. In that case I would add to the initial registry
>
> 4 - locally meaningful name
The client should be able to resolve this "locally meaningful name" to an IP
address to which it can initiate a new IKE_SA_INIT exchange. These "locally
meanin
Hello,
On 5/27/09 12:36 AM, "Yoav Nir" wrote:
> Hi.
>
> I've read through the draft again, and here are a few comments:
>
> Section 3 has the following line:
>
> If the
>IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload
Hi,
On 5/26/09 10:10 PM, "Raj Singh" wrote:
> Hi Vijay,
>
> I have some question on ikev2-redirect-10 draft.
>
> In section 5,
> --
> Once the client sends an acknowledgment to the gateway, it SHOULD
> delete the existing security associations with the old gateway by
> sending an
Hi Pasi,
On 5/26/09 1:17 AM, "pasi.ero...@nokia.com" wrote:
> There's one remaining issue that was changed due to WGLC comments, but
> the result isn't quite what it IMHO should be.
>
> When doing redirection during IKE_AUTH, in some situations the
> IKE_AUTH response with the REDIRECT is the la
Hi Yaron,
> -Original Message-
> From: Yaron Sheffer [mailto:yar...@checkpoint.com]
> Sent: Saturday, May 16, 2009 2:37 PM
> To: Vijay Devarapalli; ipsec@ietf.org
> Subject: RE: [IPsec] Redirect -09 comments
>
> Hi Vijay,
>
> Regarding loop avoidance, pleas
Hi Yaron,
On 5/13/09 10:01 PM, "Yaron Sheffer" wrote:
> Hi,
>
> While preparing to progress the draft to AD review, I reread it once again.
> Here are a few comments. Although not all are nits, none of them should block
> the document now.
>
> Thanks,
> Yaron
>
> Not-quite-nits:
Hi Tero,
On 5/5/09 4:51 AM, "Tero Kivinen" wrote:
>>> Secondly, it is not clear whether the "In such cases" only refers to
>>> the cases wher gateway decides to do something (interact with AAA
>>> server/ use external authentication server), or in all cases where EAP
>>> or multiple authenticatio
Hi Yaron,
> > The current text assumes that the IKE SA is created and needs to be
> > deleted.
> > I don't think we need to show the INFORMATIONAL exchange.
> We are not
> > modifying anything in the delete procedure. We currently have the
> > following text
> >
> >When the client
> >
Hi Tero,
Thanks for the detailed review.
On 4/28/09 7:35 AM, "Tero Kivinen" wrote:
> Section 3 says:
>
>The gateway MUST include the nonce data from the Ni payload sent by
>the initiator in the REDIRECT payload. This prevents certain Denial-
>
> but the figures showing how redirect is
Hi Pasi,
Thanks for the detailed review (again).
On 4/28/09 1:10 AM, "pasi.ero...@nokia.com" wrote:
> 1) The new versions since the previous WGLC introduced a number of
> additional steps (e.g. nonce payload, clarifying PAD etc.) to the
> redirection process, but currently these are spread over
Hi,
On 4/18/09 11:16 AM, "Yoav Nir" wrote:
> Vijay Devarapalli wrote:
>>
>> Hello,
>>
>> Yoav Nir wrote:
>>> I see that in section 6 the following:
>>>
>>>In such cases, the gateway should send the REDIRECT notification
&g
Hello,
Yoav Nir wrote:
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT a
Hi Yaron,
Thanks for the detailed review. Just responding to those that need more
discussion or where I have comments.
On 4/11/09 1:02 AM, "Yaron Sheffer" wrote:
> - 3: I suggest to start this section with an exhaustive list of locations
> where the Redirect payload can occur (IKA_SA_INIT respon
There were three changes in version 07.
- Specified that if EAP or multiple auth is used, then the redirect can
be sent in the last IKE_AUTH response message
- Added text in the security considerations that says the redirect
mechanism must not result in modifications of PAD entries
- Fixed a bu
Hi,
Kanagavel Rajan wrote:
Hello Vijay,
In section 6.2, I noticed a nonce data is included in Redirect Notify
payload as part of IKE_SA_INIT response.
But however, the payload length is set as either 13 or 25 and this does
not include the NONCE data length.
Is this a missing case in the d
Hello,
I submitted a revised document addressing some of the issues that we
have already agreed upon.
There are still two open issues
1. When to send to the REDIRECT payload when EAP or multiple
authentications are used
2. REDIRECT message and the corresponding PAD entries. The issue is
about w
exchange, the IKEv2
SA is not created. Is it enough if I say, the IKEv2 SA is not created?
This implies the client cannot continue using the current gateway.
Vijay
Thanks
Srini
-Original Message-
From: Vijay Devarapalli [mailto:vi...@wichorus.com]
Sent: Wednesday, March 18, 2009
Tero Kivinen wrote:
Vijay Devarapalli writes:
Agree. Here is the text proposal to address this issue.
If the gateway decides to redirect the client during the IKE_AUTH
exchange, based on the identity presented by the client in the
IKE_AUTH request message, it prevents the creation
Addepalli Srini-B22160 wrote:
REDIRECT notification by the responder upon receiving IKE_SA_INIT might
be exploited by intelligent injection of REDIRECT notifications. In
site-to-site VPN case, it is not difficult for attackers to know IP
addresses of gateways. UDP source port and destination por
Addepalli Srini-B22160 wrote:
From the draft, it is not clear on the VPN Responder behavior if
Initiator proceeds with SA establishment even after receiving "REDIRECT"
notification from the VPN Gateway.
Draft indicates following:
When the VPN client receives the IKE_SA_INIT response with the
Tero Kivinen wrote:
Vijay Devarapalli writes:
My proposal is to limit the REDIRECT payload to appear in message #4 (in
the first IKE_AUTH response), based on the identity presented by the
client. And leave EAP scenarios out of scope for this document.
If others feel this is needed, I am
in
the IKE_AUTH response that carries the EAP success message.
Vijay
Thanks,
Yaron
-Original Message-
From: Vijay Devarapalli [mailto:vi...@wichorus.com]
Sent: Tuesday, March 17, 2009 0:12
To: Yaron Sheffer; Tero Kivinen
Cc: IPsecme WG
Subject: RE: [IPsec] Redirect during I
ose to ignore this issue for
> simplicity.
>
> Thanks,
> Yaron
>
> > -Original Message-
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> > Tero Kivinen
> > Sent: Thursday, March 12, 2009 14:15
> > To: Vijay Devar
Hi Tero,
Tero Kivinen wrote:
Vijay Devarapalli writes:
There at least three people who think that the IKE_AUTH response
message should itself contain the REDIRECT payload. I went through the
email exchange between Fan and Tero. There was no new information
that came out of that discussion for
Paul Hoffman wrote:
At 12:44 PM +0100 3/11/09, wrote:
Vijay Devarapalli wrote:
I don't agree with the restriction that the original gateway and the
new gateway should have the same IDr. That is too restrictive. For
example, it should be possible for gw1 to redirect the client to
gw2,
pasi.ero...@nokia.com wrote:
Vijay Devarapalli wrote:
I don't agree with the restriction that the original gateway and the
new gateway should have the same IDr. That is too restrictive. For
example, it should be possible for gw1 to redirect the client to
gw2, with the two gateways havin
pasi.ero...@nokia.com wrote:
Vijay Devarapalli wrote:
- Section 6.1/6.2/6.3: should say that Protocol ID is set to zero.
Fixed.
One nit: the text in version -05 says "Protocol ID should be
set to 0". I think this should be just "is set to 0" (or
perhaps "MUST be s
Hi Pasi,
I spent about three days thinking about this, but still couldn't
conclude on anything. I am cc'ing Jari, since I thought he would
interested in this topic and have some comments.
As you observed, Mobile IPv6 does allows the mobile node to discover a
Home Agent dynamically (See RFC 5026,
ional message with a DELETE payload.
Thanks,
Yaron
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Vijay Devarapalli
Sent: Saturday, March 07, 2009 1:23
To: Tero Kivinen
Cc: ipsec@ietf.org; pasi.ero...@nokia.com; rfgrave...@gmail.com;
Tero Kivinen wrote:
Vijay Devarapalli writes:
The draft currently requires the client to delete the SA once it
receives the REDIRECT message from the gateway. I do not want the
gateway to delete the SA right away. The gateway should allow the
client to setup the necessary security associations
Hi Pasi,
Responding to the minor comments first...
On Mon, Mar 2, 2009 at 12:04 PM, wrote:
> Minor clarifications and nits:
>
> - Section 4 says "If an anycast address is returned in response to DNS
> resolution of an FQDN, the IKEv2 transaction between the VPN client
> and the VPN gateway is
Hello,
There at least three people who think that the IKE_AUTH response
message should itself contain the REDIRECT payload. I went through the
email exchange between Fan and Tero. There was no new information
that came out of that discussion for me to make this change in the
draft.
Does any one
d.
Vijay
>
> Thanks,
>Yaron
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
>> Vijay Devarapalli
>> Sent: Wednesday, February 04, 2009 2:59
>> To: Richard Graveman
>> Cc: ipsec
Hello,
On Tue, Feb 3, 2009 at 2:45 PM, Richard Graveman wrote:
> Hi,
>
>> On Tue, Feb 3, 2009 at 9:06 AM, Richard Graveman
>> wrote:
>>> Thanks. Your text is fine. The point was raised that we may not want
>>> both parties redirecting at once. In your use cases, is it always the
>>> IKEv2 respo
t-gateway scenarios.
Vijay
>
> Rich
>
> On Tue, Feb 3, 2009 at 11:27 AM, Vijay Devarapalli wrote:
>> Hi,
>>
>> On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman
>> wrote:
>>
>>>>> I just read this draft and think your idea is useful.
Hello,
Here is the proposed text for re-direct during IKE_AUTH exchange.
If the gateway decides to re-direct the client during the IKE_AUTH
exchange, it prevents the creation of a CHILD SA by sending the
NO_ADDITIONAL_SAS Notify Payload in the IKE_AUTH response. It then
follows up wi
Hi,
On Mon, Feb 2, 2009 at 10:20 PM, Richard Graveman wrote:
>>> I just read this draft and think your idea is useful. I have one
>>> question (please excuse me if it's been answered):
>>
>> Its not been brought up before. But from the beginning the focus for
>> this draft has always been on IKE
hanks,
>Yaron
>
>> -Original Message-
>> From: Vijay Devarapalli [mailto:dvi...@gmail.com]
>> Sent: Monday, February 02, 2009 21:06
>> To: Yaron Sheffer
>> Cc: Tero Kivinen; ipsec@ietf.org
>> Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_A
Hi,
On Mon, Jan 12, 2009 at 5:13 AM, Richard Graveman wrote:
> Hi,
>
> I just read this draft and think your idea is useful. I have one
> question (please excuse me if it's been answered):
Its not been brought up before. But from the beginning the focus for
this draft has always been on IKEv2 cl
Hello,
I got quite a few emails offline asking for an update of the draft. So
here it is. The only change is removal of the REDIRECT_ACK
notification payload. An empty Informational message is used by the
client to indicate that it processed the REDIRECT payload.
There is still one open issue on
eing.
>
> Thanks, and Happy Holidays!
>
>Yaron
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
>> Tero Kivinen
>> Sent: Friday, December 19, 2008 12:24
>> To: Vijay Devarapalli
>> Cc
51 matches
Mail list logo
