fan zhao | 5 Nov 2008 23:33
Picon

Re: Revised IKEv2 Re-direct draft

Hi Vijay,

Thanks for your reply. Please see below.

On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli <dvijay <at> gmail.com> wrote:
> Hi Fan,
>
> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao <fanzhao828 <at> gmail.com> wrote:
>> Hi, Vijay and Killian,
>>
>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01.
>>
>> 1) The draft describes the redirection during the IKE_SA_INIT exchange
>> and during the informational exchange that is after the SA is established.
>> Please correct me if I am wrong. I think the redirection can be done during
>> the IKE_AUTH exchange, right? We have discussed this before.
>
> Yes, but this change has not been made yet. I had presented this issue
> at the last IETF, but there were no comments. I was looking for a
> little bit more discussion on this before adding this to the document.
OK.

>
>> 2) Near the end of section 3:
>>
>>   "When this mechanism is used with Mobile IPv6, a mobile node's
>>   security associations with its home agent may expire while it still
>>   has a valid binding cache entry at the home agent."
>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is
>> the same as that of the SA. So if the SA expires, the HoA expires
>> and the BCE is invalid too, right?
>
> The home address and the binding cache entry are not marked invalid
> right away. If the SAs expire, the mobile node can run IKEv2 with the
> home agent again and request for the same home address.
OK. This can be done.

>
>>   "In this case, the
>>   mobile node MUST NOT use the original home agent address as the
>>   destination address in the IKE_SA_INIT exchange to setup new security
>>   associations.  It MUST try to setup security associations with its
>>   existing home agent."
>>
>> If I understand correctly, in this case, the MN will use the anycast address
>> in the IKE_SA_INIT, and then is redirected to the original home agent.
>> Is this correct?
>
> No, we wanted to say that the mobile node should try running IKEv2
> again with the existing home agent. Not use the anycast address as the
> destination address for the IKE_SA_INIT exchange.

I agree with what you said. Somehow, I read the text differently.

Thanks.

Sincerely,
fan

>
>> 3) Some editorial issues:
>>
>> Abstract: The proposed mechanism can
>>   also be used for Mobile IPv6 to enable the home agent to re-direct
>>   the mobile node to another home agent.
>>
>> Maybe it is better:
>> "The proposed mechanism can also be used in Mobile IPv6 ..."
>>
>>
>> 3.  IKEv2 Exchange with Redirect
>>   To redirect a IKEv2 session to
>>
>> s/a/an
>
> Thanks for catching these.
>
> Vijay
>
>>
>> Thanks.
>>
>> Sincerely,
>> fan
>>
>>
>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli <dvijay <at> gmail.com> wrote:
>>> Hi,
>>>
>>> We just submitted a new draft version for the IKEv2 re-direct
>>> mechanism. Changes made in this version
>>>
>>> - Added a section on gateway-initiated re-direct. The earlier versions
>>> only spoke about re-direct during the IKE_SA_INIT exchange
>>> - Updated the reference to IKEv2bis draft
>>> - A few other minor fixes.
>>>
>>> Vijay
>>>
>>>
>>> 2008/11/3  <Internet-Drafts <at> ietf.org>:
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.
>>>>
>>>>
>>>>        Title           : Re-direct Mechanism for IKEv2
>>>>        Author(s)       : V. Devarapalli, K. Weniger
>>>>        Filename        : draft-ietf-ipsecme-ikev2-redirect-01.txt
>>>>        Pages           : 12
>>>>        Date            : 2008-11-03
>>>>
>>>> IKEv2 is a popular protocol for setting up VPN tunnels from a remote
>>>> location to a gateway so that the VPN client can access services in
>>>> the network behind the gateway.  Currently there is no standard
>>>> mechanism specified that allows an overloaded VPN gateway to re-
>>>> direct the VPN client to attach to another gateway.  This document
>>>> proposes a re-direct mechanism for IKEv2.  The proposed mechanism can
>>>> also be used for Mobile IPv6 to enable the home agent to re-direct
>>>> the mobile node to another home agent.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-01.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>>
>>>>
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> IPsec <at> ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>>
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>
>

Gmane